Собираем эффективный отдел разработки. Как выбрать методологию для управления?
Оцениваем эффективность команды
Рекомендую начинать не с выбора процесса, по которому будет организована работа, а с подбора команды. Это фундамент для эффективного отдела разработки — ни одна методология не принесёт ожидаемого результата, пока команда не будет соответствовать определённым требованиям. Именно поэтому я уделяю такое внимание этому аспекту.
У действующих сотрудников стоит предварительно оценить эффективность. За основные критерии оценки разработчика берём:
- A. % эффективности по выработке рабочего времени (количество зарепорченных часов в месяц / количество рабочих часов месяца *100);
- B. % закрытых задач в месяц (количество сделанных задач / общее количество задач сотрудника *100);
- C. % отклонения от первоначальной оценки (количество выработанных часов в месяц / количество часов оценки в месяц по задачам *100)
Считаем итоговую эффективность по формуле: (a+b)/2 – c. За хорошую эффективность считаем итоговое значение >90%.
Для лидеров в качестве полезного времени учитываем только отведённое на выполнение задач. То есть не считаем ресурсы, затраченные на кодревью, коммуникации и другую деятельность, не связанную с кодингом.
Дополнительно можно также оценить:
- % задач с возвратами после тестирования (либо багрепортов по сделанному);
- % задач с возвратами по Code Review;
- Обратная связь от коллег по взаимодействию;
- Пунктуальность;
- Самостоятельность.
Далее делаем выводы и на собственное усмотрение либо работаем над улучшением каждого параметра по сотрудникам, которые показывают низкую эффективность, либо ищем им замену.
Увольнять ли людей из команды?
Обязательно встанет вопрос о том, стоит ли заменять сотрудников, которые стабильно показывают низкую эффективность. Это оправданно не всегда! Нужно учитывать размер заработной платы. Так, сотрудника с рыночной зарплатой, показывающего низкую эффективность, сохранять не стоит, а вот сотрудника, который зарабатывает, например, на 30% меньше рынка и при этом показывает итоговую эффективность на 30% ниже, лучше оставить в команде.
Независимо от того, по какому пути вы пойдёте, для создания эффективной команды уйдёт от 3 месяцев до года. Мы в Coral Club всегда стремимся улучшать наши процессы и развивать сотрудников, поэтому сначала делаем всё, чтобы сотрудник с нашей помощью стал эффективным, и если он заинтересован в развитии, то обязательно улучшает свои показатели.
Если работник не прогрессирует и со временем не добирается до показателей хорошей эффективности, то при решении о его замене особое внимание стоит уделить подбору кадров.
Решили искать нового человека. На что обращать внимание?
При замене кадра в готовой команде или для поиска людей в новую команду рекомендую обратить внимание на следующие параметры:
Прошлый опыт
Очень важно, как ваш будущий коллега работал на предыдущих местах, какой опыт он получил, как часто менял места работы и почему, в каких командах работал, по каким процессам и какие задачи выполнял.
Таким образом вы исключаете риски потери сотрудника в короткий срок, выявляете, соответствует ли он искомым требованиям.
Коммуникативные навыки
Эффективное общение нужно для работы в команде, особенно в условиях, когда многие команды работают удалённо.
Решение проблем
Стоит оценить, как разработчик решает проблемные ситуации, связанные непосредственно с разработкой и возникающие при коммуникациях между членами команды и другими подразделениями, проявляет ли гибкость и умеет ли слушать другие мнения и делать выводы.
Адаптивность и обучаемость
Технологии постоянно развиваются, поэтому важно, чтобы кандидаты были готовы к обучению и адаптации к новым инструментам и подходам.
Соответствие ценностям компании
Кандидаты должны разделять ценности вашей компании, быть мотивированными для работы над вашим проектом и развитием бизнеса.
Командная работа
Важно, чтобы кандидаты умели работать в команде и вносили вклад в общий успех.
Инициативность
Способность брать на себя ответственность и проявлять инициативу в решении рабочих задач повышает эффективность работы команды и положительно влияет на выполнение целей проекта.
Карьерные цели
Понимание карьерных целей кандидата поможет определить, насколько его амбиции соответствуют планам компании и как долго он в перспективе может проработать у вас.
Оценка профессиональных навыков
Анализ портфолио и/или тестового задания помогут детальнее оценить профессиональную сторону кандидата, понять, какого стиля он придерживается, соблюдает ли общепринятые паттерны и современные подходы.
Отзывы и рекомендации
Если есть возможность получить отзыв от предыдущих работодателей, это поможет сложить полноценную картину о вашем будущем коллеге. Зачастую кандидаты, находящиеся в поисках из-за желания развития и не имеющие проблем на текущем месте, без проблем предоставляют контакты.
Только после того как процесс формирования вашей команды закончен, можно переходить к выбору и внедрению методологии управления разработкой.
Приступаем к выбору методологии
Какие параметры учесть при выборе методологии:
- Специфика бизнеса;
- Что хочет видеть заказчик в процессе работы и по завершению этапов проекта;
- Стадия развития проекта;
- Тип проекта;
- Преимущества и недостатки методологии.
Рассмотрим четыре методологии: Scrum, Kanban, Waterfall и Lean, их преимущества и недостатки, а также сценарии, в которых они могут быть наиболее эффективными.
Scrum
Это методика организации рабочего процесса команды, которая основывается на поэтапной разработке и совершенствовании продукта небольшой командой специалистов разного профиля.
- Scrum подходит для компаний, где требуется гибкость и возможность быстро реагировать на изменения.
- Заказчик видит результаты каждые 2-4 недели на спринт-ревью, что позволяет ему активно участвовать в процессе разработки.
- Методология идеальна для начальных стадий, когда требования не полностью определены.
- Лучше всего использовать для сложных проектов, где продукт развивается итеративно.
- Главное преимущество Scrum в его гибкости и адаптивности. Основной недостаток — может быть сложно управлять процессами, если команда не имеет опыта работы по этой методологии.
Kanban
Это метод организации на проектах, который позволяет реализовать принцип «точно в срок».
- Подходит для организаций с постоянным потоком задач и меняющимися приоритетами.
- Заказчик может видеть прогресс в реальном времени, что обеспечивает прозрачность процесса.
- Kanban гибок и может быть применен на любой стадии развития проекта.
- Идеален для проектов с непрерывными или повторяющимися задачами, организации техподдержки.
- Преимущества включают улучшение потока работы и снижение времени цикла. Однако есть и недостатки — например, накопление задач и сложности с приоритезацией.
Waterfall
Это традиционный метод разработки, в котором каждый последующий этап начинается после завершения предыдущего.
- Подходит для стабильных компаний с четко определенными требованиями и низкой вероятностью изменений.
- Заказчик видит результат только в конце проекта или больших итераций, что может быть рискованно, если требования изменятся за время разработки.
- Лучше всего работает для зрелых проектов с известными требованиями.
- Метод хорош для проектов, где изменения в процессе разработки нежелательны или дороги. Часто используется для работы с госпроектами, также применим для разработки новой версии действующего успешного проекта.
- Среди преимуществ — предсказуемость и структурированность. Недостатки — отсутствие гибкости и риск устаревания требований.
Экспериментируем и комбинируем
Важно понимать, что все эти методологии не исключают друг друга. Они представляют собой различные подходы с уникальными принципами и практиками, которые могут быть полезны в разных контекстах. Вместо строгого следования одной методологии команды могут извлекать лучшее из каждой и адаптировать эти практики к своим уникальным потребностям.
Например, команда может использовать итеративный подход Scrum для разработки продукта, в то же время применяя принципы потока Kanban для управления непрерывными задачами поддержки и обслуживания. Для проектов с четко определенными этапами, где изменения маловероятны, может быть полезно применять элементы методологии Waterfall, чтобы обеспечить структурированность и предсказуемость. В то же время принципы Lean могут быть интегрированы для оптимизации процессов и устранения потерь на всех этапах работы.
Использование гибридного подхода позволяет командам сочетать преимущества различных методологий, выбирать те аспекты, которые наилучшим образом соответствуют специфике бизнеса, требованиям заказчика, стадии развития проекта и его типу. Это также позволяет избежать недостатков, связанных с жестким следованием одной методологии, и создает более гибкую и адаптивную рабочую среду.
В выборе методологии для вашего отдела разработки нет универсального решения — каждая из них имеет свои сильные и слабые стороны. Важно учитывать специфику проекта, команду и цели. Ориентируйтесь на потребности вашего бизнеса и не бойтесь экспериментировать, ведь правильный подход может значительно повысить продуктивность сотрудников и качество конечного продукта.
Опубликовано 04.09.2024