Разработка должна работать как система. А не держаться на героизме отдельных людей.
Разбираюсь, почему разработка буксует, зависит от нескольких незаменимых людей и требует постоянного вмешательства руководителей. Смотрю, как связаны архитектура, люди, ответственность, знания и процессы.
В разработке ПО с 2007 года. С 2018-го — управление командами и проектами.
Команда работает. Но руководителю всё равно приходится постоянно вмешиваться.
То сроки едут, то люди не договорились, то все снова ждут решения сверху. Вопрос не только в каждом отдельном случае — важно понять, почему это постоянно повторяется.
Без сильного человека всё останавливается
Самые важные решения постоянно поднимаются наверх — и организация всё сильнее зависит от одного эксперта.
Команда растёт, а продукт быстрее не движется
Каждая часть команды занята своей работой, но между ними копятся задержки: кто-то ждёт другую команду, задачи возвращаются на доработку, а важная информация теряется по дороге.
Документация есть, знания всё равно в головах
Перед серьёзным решением всё равно приходится искать человека, который помнит, почему здесь всё устроено именно так.
Руководитель постоянно спасает проект
Он подключается, разруливает, ускоряет и чинит. Каждый пожар потушен. Но пожаров меньше не становится.
Я ищу не виноватого. Я ищу причину, из-за которой проблема возникает снова.
- Кто должен принимать решение?
- Где находится нужный контекст?
- Совпадают ли ответственность и полномочия?
- Что держится на одном человеке?
- Где дело уже не в коде, а в том, как организована работа?
Четыре области, которые влияют друг на друга.
Если смотреть на документацию, команду, архитектуру и процессы по отдельности, легко исправлять симптомы и не замечать причину. Я смотрю, кто принимает решения, кто за них отвечает и где по дороге теряется нужная информация.
Сделать так, чтобы горело реже.
Сильного человека легко превратить в универсальное средство от проблем: архитектор проверит, руководитель подключится, senior быстро доделает. Это работает — и именно поэтому организация незаметно начинает от них зависеть.
Сначала причина. Потом изменение.
Я не прихожу с готовым Scrum, регламентом или заранее выбранной организационной структурой. Сначала разбираюсь, что именно мешает работе, и только потом выбираю инструмент.
Смотрю, как реально движется работа
Где рождается идея, кто принимает решения, где теряется информация и какие проблемы постоянно поднимаются к руководителю.
Разбираюсь, почему проблема повторяется
Проблему обычно видят все. Важно понять, почему она возникает снова.
Меняем то, что действительно мешает
Иногда нужен лидер. Иногда — новое правило. Иногда — один хороший документ. Реформа всей компании нужна редко.
Делаю так, чтобы изменения работали без меня
Хорошее изменение должно продолжать работать, когда моё ежедневное участие перестало быть необходимым.
Хорошая система со временем требует от руководителя меньше внимания.
Если рост команды заставляет руководителя принимать всё больше решений, знать всё больше деталей и лично контролировать всё больше людей — организация просто стала больше. Сильнее она не стала.
- Решения принимаются на нужном уровне
- Лиды отвечают за свои области и могут принимать решения
- Знания и причины решений можно передать другим
- Команды и специалисты договариваются напрямую
- Руководителю не приходится постоянно компенсировать то, что в команде не работает
Инженерный фундамент. Управленческий фокус.
Я в разработке ПО с 2007 года. Первые одиннадцать лет в основном создавал системы собственными руками, затем сместил фокус на архитектуру, передачу технических решений, людей и устройство самой разработки.
Сегодня мой фокус — выстроить работу так, чтобы команда могла самостоятельно принимать качественные технические решения и двигаться дальше без моего постоянного участия.
Обо мне и профессиональном пути →Почему капитан?
Капитан не должен собственноручно выполнять работу всей команды. Его задача — видеть ситуацию шире отдельных специалистов, распределять ответственность и добиваться того, чтобы разные части работали как одно целое.
Если без капитана команда немедленно останавливается, значит, управление слишком сильно завязано на одного человека.
Не знаете, как правильно назвать проблему?
И не обязательно. Коротко опишите, что происходит: «без меня всё стоит», «сроки постоянно едут», «команды не договариваются». Я скажу, могу ли быть полезен и есть ли смысл разбирать ситуацию вместе.