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

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

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

Ви як керівник маєте знати стан presales/engagement – тобто тощо що з певною вірогідністю стане фактичними проектами у зоні вашій відповідальності через місяць-два. Знання нових проектів – це знання нефункціональних вимог та цільових архітектур – все що визначає технічний skill set, це розуміння кількості та якості інженерного складу команди який ви маєте сформувати на момент запуску проекту.

Нагадайте мені – коли так було що для нового проекту є все що необхідно? О так, не вистачає людей, не вистачає досвіду, не вистачає знань технологій. Цей бідосік це є ваш факін джоб. А що робити коли ви знаєте стан срака-є (ass-is), голос з світлого майбутнього (вимоги до ресурсів to-be)? Так ось у вас є купа варіантів!

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

“In order to enable change, companies have to learn that keeping managers busy is a blunder. If you have busy managers working under you, they are an indictment of your vision and your capacity to transform that vision into reality. Cut them some slack.” – Tom Demarco

Найбільший гріх керівника розробників – втрати часу людей. Або незграбне витрачання їхнього часу.

Майже цитата з Peopleware, Tom DeMarco & Timothy Lister

Ви робили це 5-10-15-20-… років тому? Почуваєте необхідність писати код? Code!

Це корисно з декількох причин:

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

Вміння круто писати код без жодного досвіду роботи з людьми та відсутністю soft skils АБО вміння круто керувати іншими людьми, досвід вирішення бізнес питань без знання деталей розробки ПЗ – все це не означає що ви зможете керувати розробниками. В обох випадках більше ймовірність для провалу.

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

Чи має керівник програмістів який ставить оперативні задачі вміти розробляти код? Це дуже політичне питання, існують полярні думки та варіанти та можна витрати купу часу на it depends. Надалі не буде цього, буде проста окрема думка.

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

Питання контролю задач важливо як для розробника, так і для менеджера який постави задачу. Звісно що існує багато дуже простих задач – але навіть вони мають свої проблеми. Розгляньмо типові проблеми. (майже) Всі поради нижче мають застосовувати розробник та менеджер.

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

Оптимальна кількість відносин між людьми у софтверних проєктах залежать від специфіки як людини (інтроверт чи екстраверт), відносини між людей, так і обставин завантаження (чи робить він щось складне що вимагає концентрації). Попри те що ці складнощі вимагають універсальної відповіді “it depends” – подивімось на загальні пропорції

• Розробник – взагалі мати менше контактів, 3-4 це достатньо (1 QA, 1 PM, 1-2 розробників для взаємодії. Чому? Тому що будь-який додатковий контакт – це час який розробник витрачає на розмови та відволікається від розробки.
• Лід по компетенціях – від 4 до 6. Тому що в середньому це кілька взаємодій з кожним в середньому 0.5 години в день. Тобто 3-4 години в день на піров це Ок. Якщо ми додамо ще кілька людей – ц буде вимагати більше часу та знання більшої кількості проєктів
• Лід групи – вимагає від 0.5 до 1 години на людину в середньому в тиждень. Комфортне навантаження – десь 3 години в день. Тобто це десь 15-30 фахівців на ліда групи. Залежно від складності людей, досвіду роботи з ними – пропорції витрат часу можуть суттєво змінюватись. Так для більше автономних фахівців достатньо 0,5 години на 2 тижні.

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