Хотел бы еще добавить, что найма специалистов не достаточно. Можно нанять тестировщика, аналитика, лида и менеджера, но без описанных воспроизводимых процессов команда не начнет работать эффективно и предсказуемо.
Например, не достаточно нанять тестировщика, чтобы уменьшить количество багов. Еще нужно зафиксировать структуру баг-репортов, чек-листов тестирования, прописать ответственность.
Найм аналитика не уменьшит количество итераций переделывания задач, если команда не следует какому-либо стандарта описания требований, и т.д.
Чтобы команда вовремя всё успевала, нужно не только снять с менеджера лишнюю нагрузку, но и бронировать время под планирование с актуализацией оценок и плана, а также делать это планирование прозрачным для всей команды, чтобы обо всех ограничениях и сроках знал каждый участник.
Короче, не только найм, но и процессы важны.
Официально подтверждаю, что цель была именно такой 😘
Как программист, согласен со всем 🫡
Искренняя благодарность за новое слово «шизопоток»
Жизнь ведь и состоит из преодоления трудностей, это делает нас сильнее!
Здравствуйте!
Если коротко, тимлид этого не делает, но если надо, то делает.
Разбиение такое: менеджер эффективно декомпозирует типовые задачи, которых, на самом деле, большинство. За сложные и нетиповые вещи отвечает тимлид, но этого, по моим ощущениям, не больше 20% от работ. В результате у тимлида освобождается много времени на что-то другое.
Всё, конечно, зависит от проекта, потому что иногда, наоборот, очень много сложного и нетипового. Но по своему опыту скажу, что менеджеры — не глупые люди и даже на сложных проектах спустя какое-то время въезжают и начинают успешно справляться с декомпозицией и распределением большинства задач.
Чтобы понять, является ли процесс типовым или нетиповым, существуют этапы аналитики, встречи по планированию и пр., где отслеживаются все возможные вопросы.
Здравствуйте!
Если говорить о стажерах, то это похоже на правду. Стажер — это сотрудник без опыта продуктовой разработки. Часто для него это в принципе первая работа. Поэтому стажера нужно максимально эффективно погружать в процессы, чтобы он как можно скорее начал приносить пользу компании. Первые несколько месяцев после трудоустройства стажер — это не плюс в команде, а скорее уменьшение производительности его руководителя.
Но в статье речь не о стажерах, а о команде в целом. В общем случае мы, конечно, полагаемся на самостоятельность сотрудников, их проактивность и т.д. Но также важно учитывать, что время разработчика очень дорогое, поэтому компании максимально не выгодно тратить его на рутинные задачи или на прокрастинацию.
Человек наиболее эффективен, если вокруг минимум неопределенности, и общая задача менеджера и лида — снизить неопределенность и создать условия, в которых разработка ведется эффективно, предсказуемо и результативно:
— временные оценки задач адекватны их размеру
— фактическое время выполнения задач соответствует оценкам
— результат работы — готовое ПО, решающее поставленные задачи.
При этом, действительно, важно не переусердствовать:
— помимо того, чтобы снимать с разработчика неопределенность и разжевывать для него требования, его нужно развивать, чтобы в какой-то момент он вырос и смог справляться самостоятельно. Короче, постоянно нужно следить за тем, чтобы разработчик расширял свою зону ответственности и успешно с ней справлялся.
— коммуникация должна оставаться в первую очередь деловой. Лид и менеджер не как мамочки заботятся о разработчиках, а просто работают в рамках своей роли: выполняют свои обязанности, конструктивно помогают, подсказывая векторы для развития. Разработчик тоже должен это понимать и не ожидать, что всё за него сделают.
Здравствуйте. На самом деле, нам такой подход позволяет эффективно работать и над технически сложными проектами. О них вы можете почитать в нашем блоге на Хабре. Собрал небольшую подборку наших технических статей, которые были интересны лично мне:
1. Back: «Изобретая бота: система обработки сообщений на примере конструктора чат-бота»
https://habr.com/ru/company/vk/blog/697024/
2. DevOps: «Зачем мы сделали собственный контроллер для копирования секретов в Kubernetes»
https://habr.com/ru/company/kts/blog/682062/
3. Front: «Игра с голосовым управлением на React и Phaser»
https://habr.com/ru/company/kts/blog/578102/
4. Front: «Пятёрочка — Интегрируй меня полностью». Как мы сделали фронтед личного кабинета для 260К сотрудников X5 https://habr.com/ru/company/kts/blog/569448/
Здравствуйте, отвечаю на ваши комментарии:
1. В любой момент времени в проекте есть кто-то, кто обладает наибольшей компетенцией. Этот человек чаще всего лид проекта, и на нем ответственность за конечный результат. В этом блоке речь идет о валидации решения. Проработку предложения по архитектуре и реализации, конечно, можно и нужно делегировать — так развивается команда и решается проблема bus-фактора. Но опять же, ответственность за финальное решение на лиде. Если лид идет в отпуск / заболевает / увольняется / etc., в экстренном порядке можно получать внешние консультации от других лидов их проектов, временно предложить им вести проект, с постепенной передачей роли лида другому сотруднику. В целом, текущий лид проекта должен выстраивать работу так, чтобы не быть незаменяемым и развивать других сотрудников на замену себе.
2. Проблемы сотрудника на одном проекте — не всегда следствие его необучаемости. Очень часто это признак выгорания, или, возможно, проект человеку субъективно не нравится. И практика показывает, что перевод сотрудника на другой проект позволяет сильно увеличить его вовлеченность, мотивированность и, следовательно, эффективность. Много комментов на код-ревью здесь тоже скорее пример низкой вовлеченности сотрудника.
Приятно иметь честь отнести себя к обеим этим категориям 🥰
Да, поэтому нужны и найм и процессы. Найма без процессов не достаточно. Процессы без людей, кто их будет обеспечивать, тоже не поедут.