Ответ на пост «Что мешает исполнителю стать руководителем»⁠⁠1

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

1. Есть задачи которые нельзя давать одним сотрудникам, но можно давать другим. Просто из-за склада ума. С каждым сотрудником надо держать в уме, или записывать, какие типы задач ему даются. И мотивированному сотруднику нельзя давать задачу с которой он не справится - бьёт по психике и самооценке.

2. У сотрудников есть свой стиль исполнения задачи, его надо учитывать. Кто-то изноется, кто-то доведёт до дедлайна, что бы потом ударными темпами делать. Кто-то не умеет в декомпозицию большой задачи на отдельные кусочки. Встанет перед большой задачей и не знает как её делать.

3. Есть трудноформализуемая черта, связанная то ли с опытом, то ли с интуицией, то ли с кругозором, которая позволяет не застревать надолго в тупиковых направлениях. Поясняю - в IT в целом (и в программировании в частности) задачу можно выполнить разными способами, большим количеством. И даже маленькие подзадачки, как правило, позволяют применять разные подходы к решению. Владельцу задачи или заказчику как правило без разницы такие тактические маневры, лишь бы был результат. А вот некоторые сотрудники могут "упереться рогом" в тупиковый вариант и рыть копытами землю день, другой, третий - лишь глубже закапываясь и хороня сроки и бюджет. И вот такая черта - упереться и копать землю - очень злит. Ну не получается так, остановись, подумай, выбери обходной путь - сделай иначе, - нет! Будет страдать, напрягаться и всё без толку...

Очень важно учитывать эту черту и периодически разбор задачи проводить и текущее состояние. Даже если задача руководителю кажется небольшой и нетрудной.

4. Опыт показывает, что в рамках одной задачи нужно держать компетенции двух человек. Т.е. если есть выделенный, ограниченный рамками технологии и бизнес-задачи проект, даже небольшой (допустим на 20 человеко-часов работы) - лучше что бы в курсе этой задачи были два исполнителя и оба принимали участие в работе. Один как ведущий, второй на подхвате. Да, эффективность снижается, зато снимаются риски больничного, отпуска, увольнения, выгорания или переброски ведущего на более важный фронт работы. Всегда, как план Б остаётся второй исполнитель. Ведь зачастую "въехать с нуля" в проблематику задачи и понять логику предпринятых действий требует больше времени и сил чем уже затрачено или ещё осталось до конца.

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