Робота з негнучкими програмістами

Іноді програмісти, які працюють над проектом тривалий час, стають негнучкими, і з ними стає важко міркувати. Навіть якщо нам вдасться переконати їх, вони навряд чи зможуть реалізувати наші пропозиції.

Наприклад, я нещодавно приєднався до проекту, де процес складання та випуску занадто складний і не має зайвих доріг.

Я запропонував нам позбутися частини накладних розробок (наприклад, заповнення декількох електронних таблиць), просто інтегруючи засоби управління дефектами та засоби контролю версій (обидва - це інструменти IBM-Rational, тому інтеграція може бути дуже легким одноразовим зусиллям). Крім того, якщо ми використовуємо такі інструменти, як Maven & Ant (проект включає Java та деякі продукти COTS), побудова та випуск може бути спрощена, що має зменшити помилки вручну та втручання.

Мені вдалося переконати інших і я готовий докласти зусиль, щоб розробити доказ концепції. Але розробник "Старший" не бажає, можливо, тому, що поточний процес робить його більш цінним.

Як ми вирішуємо цю ситуацію, не розвиваючи тертя в команді?

Ти новий член команди, і ти хочеш змінити деякі фундаментальні аспекти роботи команди. Удачі, я відчуваю щасливий колектив у вашому майбутньому.

Гаразд, кілька практичних порад:

Доведіть себе команді. Це потрібно зробити з точки зору технічної та надійної надійності. Якщо ви хочете, щоб люди стежили за вами, вам потрібно дати їм це зробити.

Розуміти історію методології. Чому воно існує? Яку проблему вона вирішувала на той час? Переконайтесь, що ваше рішення справді користь для команди. Можливо, ваші зміни краще, але вони насправді не можуть вирішити проблему, яку має команда.

Ознайомтесь із своїми блоками. З’ясуйте причини їх опору та працюйте над цими предметами.

Якщо ви хочете бути агентом змін, навчіться бути успішним агентом змін . Десятки книг та інших джерел, що надають вам набагато більше інформації, ніж ви отримаєте тут.

І так, бажаю вам удачі. Але, будь ласка, заради вашого щастя та щастя вашої команди будьте уважні до цього. Ваше бажання змінити процес, не вкладаючи енергії для того, щоб прокласти правильний шлях, може принести набагато більше шкоди, ніж користі.

Я був на посаді, яку ви згадали. Я провів роки як розробник Java і врешті-решт пішов на роботу, де всі вони використовували Smalltalk. Моя перша реакція була "OMG, вони використовують цю старожитну технологію", і я почав намагатися вирішувати конкретні проблеми Smalltalk з рішеннями Java. Я можу лише уявити, який головний біль у мене був у інших розробників, і вони ненавиділи Java з пристрастю.

Лише мені не дали середнього проекту, над яким я працював, коли мене провели протягом кількох місяців два старших розробника, і я почав займатися мовою Smalltalk і навчитися їй подобатися. Поки я покинув цю роботу та повернувся до розробки Java, я відчуваю себе набагато гнучкішим, тому що можу взяти проект та реалізувати його незалежно від мови, якою користується компанія. Основне, щоб ці люди зрозуміли, це те, що мова - це не що інше, як носій. Я також взяв час, щоб навчити себе Лісп та Ерланг, але це може не працювати з усіма.

Як стратегія побудови команди, я рекомендую сім мов за сім тижнів людям, з якими у вас виникають проблеми.

Я думаю, це також зводиться до того, скільки часу ці люди готові вкласти гроші, щоб стати більш гнучкими. Проблема з більшістю університетів (принаймні тих, кого я бачив) полягає в тому, що вони налаштовані на певну мову та її студенти стають «інституціоналізованими», як ви вже згадували. Я думаю, що частиною вашої стратегії має бути виховання гнучкості у вашій команді. Це можна доповнити розробкою, керованою доменом .

(1) Моделюйте домен (простий) (2) реалізуйте його за допомогою двох різних мов (тобто Java та Lisp)

Знову ж таки, це припускається, що вони вмотивовані робити вищезазначене і готові вкласти власний час для досягнення цього.

Сподіваюсь, це допомагає

Я можу бути тут абсолютно неправильним шляхом, але мені здається, що одні й ті ж проблеми є загальними в більш широкому масштабі і стосуються людського консерватизму. Люди часто відмовляються змінювати загальновідомі моделі поведінки з причин, які занадто багато для згадки.

Будучи російським розробником (і, отже, бачу менше раціонального західного прагматизму), я бачу практичні міркування набагато менш переконливими, ніж намагатися ходити в чужих черевиках.

Іншими словами, ви згадали, що старший програміст цінує власну позицію, пов'язану з діючою робочою схемою. Можливо, вам слід переконати його в тому, що новий спосіб робити речі зробить його становище ще більш цінним, і існує багато способів це зробити. Наприклад, ви можете змусити його насправді виголосити свою ідею і отримати кредит за неї, або ви могли знайти конкретне місце в процесі, яке він може контролювати виключно і т.д.

Я вважаю, що бути гнучким поза очевидними перевагами вашої ідеї, тут може стати вашим магічним заклинанням.

Мені вдалося переконати інших і я готовий докласти зусиль, щоб розробити доказ концепції. Але розробник "Старший" не бажає, можливо, тому, що поточний процес робить його більш цінним.

Замість того, щоб викидати асперсії на персонажа старшого розробника (поганий хід), можливо, вам слід спробувати зрозуміти, чому він не ентузіазм:

• Можливо, він вважає, що ви один із тих людей, які перепродають їхні ідеї. Можливо, він сумнівається, що ви можете їх доставити.

• Можливо, він думає, що ви перебільшуєте проблеми. (Вони не можуть бути такими поганими ...)

• Можливо, він думає, що ви не повністю розумієте технічні ризики.

• Можливо, він думає (знає), що зараз є важливіші речі, які потрібно зробити.

• Можливо, ви просто потріть його неправильно.

Моєю порадою було б довести йому себе. Як, наприклад, надаючи проекти, які вам насправді дали. Коли він більше довіряє вашим здібностям та судженням, перегляньте це питання.

Якщо ви хочете переслідувати "поліпшення процесу" прямо зараз, моя порада буде робити це повільно, невеликими кроками.

Майте на увазі, що, безсумнівно, існує ризик, що запропоновані вами зміни масово вплинуть на продуктивність вашої групи та навіть їх здатність підтримувати наявне програмне забезпечення. Якщо це станеться, відповідальна особа, швидше за все, отримає найбільшу частку від вищого керівництва.

Інституціоналізовано про що зокрема? Технології, зразки, практики?

Якщо вони давно були в організації / проекті, швидше за все, вони є старшими розробниками і мають відповідальність / досвід для здійснення цих дзвінків, і досвід у проекті, а не просто обумовлений, як експеримент 5 мавп .

Рішення переконливого їх залежатиме від того, що є предметом, оскільки якщо вже обраний зразок / технологія, це буде вагома причина, і для того, щоб виправдати викидання з роботи та повторне ознайомлення тощо, доведеться мати кращу причину. ., якщо так, рішення архітектора / старшого розробника організує зустріч, щоб демократично вирішити найкраще рішення.

Якщо команда дійсно має непотрібні дорожні блоки, то, ймовірно, вони будуть найбільш раді, якщо ви допоможете їм виправити їх. Однак зауважте, що для їхнього існування може бути дуже вагома причина, і ви будете виглядати дурними, якщо вам доведеться сказати "о, ну, моя фантастична ідея не працює", після того, як довго її перепродавати всім.

Спочатку досліджуйте, а потім виходьте. Також зауважте, що вміти показувати, як ви пропонуєте покращити його, набагато краще, ніж рукоділля.

Я схильний сказати, що ви є тим, хто є "негнучким програмістом". Ви новачок у проекті, але ви наполягаєте на тому, щоб ваша ідея була найкращою, а хлопець, який веде проект, довший і знає систему всередині та ззовні - просто від свого рокера.

Я досить досвідчений і досить добре оцінений, і часто доручаю вирішувати складні проекти як член команди тигра. Навіть тоді я все ще знаходжу час, щоб вивчити як, як, динаміку команди, проект та їх практику, а не дико вступати і розповідати, як це і що не так. Насправді я ніколи не кажу, що вони роблять неправильно, оскільки це не отримує відповіді, яку я хочу, і зазвичай те, що вони роблять, не є помилковим, воно просто потребує певного налаштування.

Кожен проект унікальний. Кожна команда унікальна. Ваше рішення може бути кращим для вас та розробників, але це може бути не краще для керівника, замовника, бізнесу чи проекту, але оскільки у вас немає досвіду роботи з проектом, щоб краще знати, ви б не знали відповідь на це.

Найкращий спосіб змусити людей робити те, що ви хочете, - змусити їх думати, що все є їх ідеєю. Тому замість того, щоб безпосередньо вносити пропозиції, представляйте варіанти. Якщо ваші ідеї явно кращі за альтернативи, дайте можливість старшому деві забрати їх та зробити їх своїми. Не турбуйтеся про отримання кредиту. Люди, які мають значення, будуть знати, що відбувається.