Як продемонструвати керівництву, що посередні розробники завдають шкоди команді [закрито]

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

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

Цим розробникам не лише бракує навичок з концепціями програмування, але й загалом здатності формулювати рішення проблеми в коді. Прості речі, такі як написання циклів, для них важкі, не кажучи вже про розробку та реалізацію рішення проблеми.

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

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

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

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

Які ще ресурси є? Книги, статті, загальні поради будь-що було б корисно.

Проблема пов'язана з відсутністю навичок чи здібностей, проблемами ставлення з боку програмістів або корпоративною культурою, яка не сприяє належній трудовій етиці?

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

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

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

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

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

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

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

Можливо, вам слід пройти навчання.

Можливо, вам слід прочитати звіт про вас .

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

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

У такому випадку припиніть скаржитися і приступайте до роботи. Не як кодер, а як менеджер.

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

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

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

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

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

Я вже був у цій ситуації і, безумовно, можу співчувати. Я зробив, щоб усунути невелике, замкнуте в собі завдання, яке повинно зайняти мене чи іншого старшого розробника не більше ніж через 2 дні. Для цього завдання я б створив збірки документації, що визначають, як слід впроваджувати рішення, будь-які зміни бази даних тощо. Потім я сідаю до розробника, даю їм проходження завдання на високому рівні та призначаю їм з кінцевим терміном 1 тиждень. Наприкінці тижня у вас є щось відчутне, з чим можна порівняти їх роботу: чи вони зустрічались із специфікацією? Як вони зроблені? Скільки помилок виявила система контролю якості? Вони якось порушили процес побудови або перерви?

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

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

Моя порада така:

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

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

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

До речі, ми використовували BugTracker.Net .

Цікаво, як ці люди взагалі потрапили в компанію:

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

Прості речі, такі як написання циклів, для них важкі ...

Без сумніву, вашій компанії потрібно вкласти більше часу та зусиль у набір робочої сили, як каже стара приказка: поспіх робить марнотратством.

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

Я читав це деякий час тому про заохочення програмістів хотіти бути найкращими.

Ботанічний пастух

Ви згадали, що для своєї команди ви "надаєте відгук про їх ефективність".

Так:

1. Сідайте зі своєю командою.
2. Роздайте їм роздруківки цієї сторінки та скажіть, що ви опублікували це про них.
3. Нехай читають.
4. Попросіть їх допомогти вам вирішити проблему.
5. Послухай і запиши.
6. Віднесіть це до своєї управлінської команди.

Peopleware - це ще одна книга, яка має приєднатися до вашого списку.

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

Здається, ви на правильному шляху.

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

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

Покажіть цифри вищому керівництву, вони тепер повинні переконатися.

Книга

Code Complete: Практичний довідник з побудови програмного забезпечення Стіва Макконнелла

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

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

Потім покажіть, як команда кращих розробників може покращити рентабельність інвестицій.

Зберігайте звіт стислим. Не робіть це багатослівним. Поставте це з точки зору того, скільки грошей вони втрачають на цьому.

Зараз у нас є інструмент, який вимірює складність наших модулів коду. Він працює на наших модулях PL / SQL, але я вважаю, що є інструменти, доступні в інших середовищах.

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

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

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

(Окрім того, весь код зараз подано на перевірку, і має бути наданий супровідний аналіз коду. Тут справа, безумовно, покращується.)

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

Просто ідея.

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

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