Чи завжди розширення команди розробників сприяє ефективності? Обговорюємо

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

Чи знаєте ви якісь ефективні стратегії для покращення продуктивності розробників, окрім як банального найму більшої кількості фахівців? Діліться у коментарях 👇

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Закон Брукса відомий всім, але ніхто ним не користується.
Історія, що повторюється без кінця:
Команда опиняється за графіком, і тут на сцену виходить PM з класичною реплікою: «Нам потрібно більше людей!».
Але часу в обріз, тож замість кваліфікованих фахівців зі стеку проєкту вибирають перших-ліпших.
Що виходить далі? Запуск проекту відкладається ще довше, а витрати зростають, адже доводиться витрачати час на навчання новачків та виправлення їхніх помилок через брак досвіду.

Стратоплан кажуть, що додати сініорів буде ще більшою помилкою — це вже буде гасіння пожежі за допомогою вибухівки. Менеджер отримає собі ще і скандал — коли йому/їй скажуть : «А що ти робиш?». А існуючи сініори — затаять злобу, та будуть саботувати онбордінг.
Сенс у тому — що психологічно сказати замовнику чи бому — або якімось іншим стекхолдерам (людям які приймають рішення — тобто керують фінансами) «ні», зокрема викинути з продукту фітчі які там не є конче необхідними, завжди більш ссикотно, ніж : розвалити команду, простати делайн та заовербеджети.

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

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

Навпаки воно може подіяти в довгу, і додавати треба командами — а не окремими людьми. Усе же ніби як давно відомо та описано у числених авторів, є купа чисельних дослідів тощо. Бери та роби за книжкою.
Для більшості проектів, які відстають за графіком для продук овнера спрацює дві речі — перша пріорітезація задач, за моделлю Кано en.wikipedia.org/wiki/Kano_model або MoSCoW method en.wikipedia.org/wiki/MoSCoW_method або будь якою іншою дієвою. Тобто треба викинути з плану хотілки які не є життєво необхідними в продукті (не той випадок як відсутність шрифтів в комп’ютерах Ліса наприклад, бо такий комп’ютер тоді не вартує тієї ціни позаяк нічим не вирізняється від дешевших і взагалі друкарської машинки, тому цільова аудиторія видавців такий комп’ютер не куплятиме тобто це Must have, тоді як наприклад систему яка займається передачею зображення не принтер можна ліцензувати у сторонньої компанії як то Xerox тобто це should have і т.д.). Друга річ — це менші задачі. Овертайми рекомендуються лише тоді коли вони потрібні, наприклад безпосередньо в реліз.
В цілому є купа книг, той же Deadline від Тома Демарко, купа тренінгів мільйона компаній тощо. Нажаль ці прості правила як не знало пів індустрії, так і досі не знає. Я з цим стикаюсь на протязі усієї кар’єри в ІТ, мало не звжди андер естімейт, перенапружена команда з 20+ людей, з умовних 10 задач усі мають пріоритет must have. Ризики якщо і є виявлення , нема а ні плану щодо зниження такого ризика, ані відповідальної особи яка цим ризиком займається і тому подібне.
Так треба сказати стосується звісно далеко не усіх, в індустрії повно грамотних людей і в менеджменті, ІТ бізнесі та бізнес аналізі також.

коли розширення команди інженерів не допомогло пришвидшити розробку?

Карул в нас пожежа, чим її тушать ? — Рідиною — То давайте візьмемо найдорожчу — бензин !

Мементо Фредерік Брукс
uk.wikipedia.org/wiki/Закон_Брукса
P.S. Не знання елементарних правил розробки ПЗ, як то закон Брукса, методик постановок цілей, методик з’ясування пріорітетів задач, методів оцінки ризиків тощо, годує галероводів вже декілька десятиліть і не просто годує, а з чорною ікоркою яку забирають заїджаючи за нею в ікродрайв на жовтих мустангах та теслах.

’Ефективні менеджери’ з PMP та MBA — сприяли збільшенню кількості звітів та показників

Зависит от размера команды. При хорошо спланированной работе иногда действительно можно всё улучшить количеством людей. Если людей достаточно, но всё равно медленно — искать новый подход.
Если людей достаточно, подход хороший и план есть то уже особо ничего не сделаешь, но можно какие-то части разработки аутсорсить.

Так же иногда помогает процессный аналитик, когда всё начинает упираться в длительность-сложность принятия решений или изменений.

Каждой ситуации своё решение.

Збільшенню ентропії сприяє точно.

другий закон термодинаміки досі працює)

Підписатись на коментарі