В чем залог успешного управления разработкой? Об этом знает только хороший директор по разработке, хотя весь секрет состоит в правильном руководстве персоналом, продуктом и применяемыми технологиями. Давайте рассмотрим, как стать таким директором и как в его роли преуспеть.
Обязанности разработчика ПО обычно определены четко: есть задачки, их нужно сделать эффективно и в срок. А вот обязанности директора по разработке определить не так просто. Управление — процесс сложный, в нём просто не существует простых и чётких ответов на все ситуации и проблемы. Так что твой успех в директорской роли будет зависеть от того, насколько хорошо ты сможешь управлять своими подчиненными и продуктом, а также технологиями.
Главное — люди!
В роли директора твоим приоритетом станет команда. Как сделать её по-настоящему сильной?
Строим команду, формируем атмосферу доверия
Если команды ещё нет, то первым шагом, очевидно, нужно нанять правильных людей.
Неудачный найм — это трата времени и для кандидата, и для всех членов команды. Волей-неволей они будут тащить его, компенсировать его слабые стороны, это всех сильно деморализует и уж точно скажется на качестве работы. При этом даже самый выдающийся профи может не вписаться в культуру команды.
Поэтому на собеседовании важно задавать не только технические, но и открытые вопросы о работе в команде или принятии на себя руководящей роли. Например, можно спросить:
- С какими сложными ситуациями претендент в последнее время сталкивался?
- Как он их разрешил?
- Какие альтернативы своему решению он рассмотрел?
В завершение этого блока вопросов можно попросить рассказать о последнем кризисе, реакции на него, что было сделано чтобы не дать ему повториться.
Состав команды утрясся? Время выстроить уважительные и доверительные отношения с каждым её членом. Без них об эффективном руководстве или даже здоровых взаимодействиях речи не идёт. Нужно будет выделить определённое время, чтобы понять карьерные цели каждого и вообще выделить приоритеты сотрудников. Очень полезны для этого встречи один на один — они помогут лучше познакомиться и притереться с каждым. Как часто должны проходить такие встречи? Зависит от конкретных потребностей членов команды, но стоит встречаться хотя бы пару раз в месяц. Но, если команда большая или сотрудничество интенсивное и постоянное, можно проводить такие собрания и реже, например, раз в месяц.
Как прокачать свою команду?
Большая часть работы директора по разработке заключается в выявлении сильных и слабых сторон каждого сотрудника. Новичков или отстающих нужно объединять с опытными разработчиками, это сгладит работу. Полезно будет почаще проводить проверки написанного кода. Но основное внимание сосредоточь на том, что у них лучше всего получается. Именно наши сильные стороны мотивируют нас и приносят больше всего позитивна от работы.
Чтобы создать сильную команду и мотивировать каждого её члена показать себя, нужно распределять задачи, основываясь на способностях и чертах характера каждого из них. Для этого неплохо будет выявить неработающие или просто недостаточно оптимальные участки кода, а также человека, который их написал.
Хорошие сотрудники всегда будут стремиться учиться новому, совершенствоваться и расти в областях, которые важны для них самих и для всей команды в целом. При этом роли и обязанности каждого не могут оставаться статичными — то, что имело смысл в прошлом году, в следующем, возможно, себя для них исчерпает. Чтобы гарантировать, что каждый член команды продолжает расти над собой и совершенствоваться можно использовать следующие методы:
- Пристально следи за их личностным ростом, инвестируй в их развитие и помогай им реализовывать свои амбиции.
- Организуй встречи чтобы составить план личного развития и дать сотрудникам возможность наметить свою карьерную стратегию.
- Постарайся выделить каждому дополнительное время для саморазвития, разрешай членам команды периодически меняться ролями. Организуй внутренние семинары и обучающие курсы.
Но кроме обеспечения роста каждого сотрудника нужно также подстраховать всю команду. Нужно давать своим сотрудникам иногда принимать решения, не боясь неудачи. Если что-то вдруг пойдёт не так, надо будет собрать волю в кулак, взять всю ответственность на себя, а впоследствии учесть все ошибки – свои и командные.
Благодаря этому сотрудники день ото дня будут становиться решительнее, пробовать новое и быстрее развиваться. Ошибки обязательно будут время от времени происходить, но в этом нет ничего страшного, а грамотная и своевременная обратная связь предупредит их повторение.
Управление продуктом
Вторым важным аспектом роли директора по разработке является работа с разрабатываемым ПО. Для этого просто необходим тесный контакт с руководителем проекта, а также согласование ожиданий, умений и навыков команды на создание именно того продукта, который всех удовлетворит.
Можно выделить шесть основных обязанностей, которые директору по разработке придётся взять на себя:
1. Верная расстановка приоритетов
Каковы цели и задачи команды на ближайшие полгода-год? Кто является конечным потребителем продукта? Чего он ожидает от него? Наверное, горизонт представлений команды о своей работе — всего несколько недель, и для них и того бывает достаточно. Но на уровне директора крайне важно понимать, что представляет собой проект в целом и каким должна быть его финальная версия.
2. Активно участвуй в принятии решений
Директор по разработке глубже вовлекается в разработку и обновление продукта, чем остальные. Придется работать с разными отделами и командами, много и активно сотрудничать в паре с руководителем проекта. Не обязательно соглашаться с каждым его решением, но верить в то, над чем вы вместе трудитесь, стремиться сделать финальный продукт как можно более совершенным — необходимо. Можно оспаривать отдельные решения, но последнее слово все равно остается за руководителем. Для слаженной работы необходимо чтобы между вами установилась атмосфера взаимоуважения и поддержки.
3. Определи техническую стратегию и методологию разработки
Работа руководителя проекта заключается в определении концепции и стратегии его развития, а твоя — в работе над его архитектурой и технической составляющей. Поэтому вся ответственность за определение методологии разработки и её внедрение в работу команды на тебе. Помни: руководитель проекта владеет продуктом, но ты и твоя команда его реализуете.
В некоторых случаях, можно внедрить полезные функций, задействовав при этом минимум усилий. Например, обновление платформы, на которой пишется проект, до новой версии, может помочь реализовать конкретную функцию быстрее и эффективнее. Качественный обзор продукта может помочь тебе и всей команде выявить такие случаи и предложить их на рассмотрение руководителю проекта.
4. Сбалансируй технический долг и разработку новых функций
Важнее всего выпустить продукт на рынок вовремя, поэтому накопление технического долга неизбежно. По мере развития продукта акцент обычно смещается на добавление новых функций и улучшений, но прекращать процесс погашения технического долга неприемлемо. Если не адресовать изначально возникшие проблемы в коде, внедрение новых функций займет больше времени и обойдется дороже. Фиксируй компромиссы, на которые вам приходится идти, и ищи баланс между закрытием долгов и проработкой новых функций продукта.
5. Используй технологии и автоматизацию для управления техническим долгом
Нужно будет использовать статический анализ, чтобы выявить наиболее требующие доработки участки кода и установить приоритеты рефакторинга. Это поможет улучшить производительность продукта и ускорить работу над новым функционалом.
6. Убедись, что разработка идет гладко
Всегда нужно помнить, на каком этапе находится проект. Если команда отстает от графика, нужно знать, почему, и заниматься устранением причин. Например, регулярные технические сложности должны вызывать реакцию: можно организовать сеансы парного программирования, это улучшит обмен знаниями в команде. Если команда тратит много времени на развертывание кода на серверах, нужно автоматизировать процесс, чтобы сэкономить время и сократить количество возникающих ошибок. Помехи в работе нужно свести к минимуму, инструкции по работе как над новыми задачами, так и над исправлением багов, нужно формулировать предельно чётко.
Технология и делегирование полномочий
Директор по разработке остаётся разработчиком, просто работа с кодом теряет для него приоритетность. За технические решения будут отвечать твои подчинённые: генерал не выходит на поле боя с винтовкой, а директор по разработке не занимается каждой строкой кода на микроуровне.
Тем не менее, твои знания и опыт понадобятся, чтобы убедиться, что решения старших специалистов соответствуют составленному плану и направлению развития проекта. Делегируй технические решения команде, но не забывай модерировать их работу, чтобы гарантировать масштабируемость, безопасность и надежность продукта.
Задавай им непростые вопросы, которые касаются непредвиденных обстоятельств. “Что если пользователей станет в 20 раз больше? Выдержит ли ПО такую нагрузку?” “Будет ли эта технология по-прежнему поддерживаться через два или три года?”
Можно и даже нужно предлагать альтернативные решения и фреймворки. А вот принуждать команду ни к чему не надо. Помимо технических предложений можно давать рекомендации по разработке и методологии.
Кроме того, обязательно нужно следить за ключевыми показателями продукта. Необходимо учитывать как технические, так и бизнес-показатели. DevOps поможет создать аварийных сигналы для мониторинга системы и держать команду в курсе о возникающих проблемах. Наконец, нужно разработать методологию устранения инцидентов, чтобы гарантировать, что они не повторятся.
И последнее, но не по важности: всегда нужно быть в курсе новейших технологий и тенденций. Чем больше решений и фреймворков будет в вашем распоряжении, тем лучше. Выдели время на чтение статей, проведение обзоров кода и участия в технических обсуждениях со своей командой.
Директор, который в курсе технических новшеств и тенденций, вызывает у своей команды уважение. Ну а осведомленность о новых трендах поможет создать атмосферу любопытства в коллективе и побудит сотрудников искать новаторские способы решения сложных технических проблем.
Автор — Георгий Далакишвили. Источник.