Меня зовут Илья Китанин, я руководитель команды разработчиков Cofoundit — сервиса по поиску сотрудников для стартапов.
Сегодня я расскажу вам, как, используя статистику и принципы гибкой методологии, работать со сторонними разработчиками максимально эффективно, не переплачивая и в установленные сроки.
Предыстория и подготовка
С марта 2016 г.Соучредитель работали в ручном режиме: мы сами подбирали сотрудников и сооснователей стартапов и изучали потребности пользователей.
Мы собрали требования и в июне начали разработку сервиса.
Два месяца ушло на создание прототипа и еще месяц на доработку финальной версии.
Мы начали работу над продуктом в середине июня, в августе выпустили закрытую бета-версию, а официально запустили в конце сентября и продолжаем работать.
С самого начала я рассматривал Agile только как методологию.
Первую неделю мы посвятили планированию: разбили задачу на небольшие задачи, запланировали спринты, каждый длиной в неделю.
Большинство задач укладывалось в один спринт, но поначалу на некоторые уходило два или три.
Первые спринты оказались откровенно неудачными — мы задержали релиз на неделю и начали отставать от графика.
Но этот опыт помог нам правильно оценить сроки и отказаться от избыточного функционала.
Изначально мы хотели сделать сервис с симметричным поиском: чтобы и специалист, и проект могли просмотреть профили друг друга и начать общаться.
В результате в работе осталась только первая часть: кандидат может просматривать и выбирать профили стартапов, а проект видит только тех специалистов, которые уже проявили к нему интерес.
То есть, по сути, мы запустили минимально жизнеспособный продукт.
Управление производительностью
Используя Jira и плагин «Время в статусе», я постоянно отслеживал, как работает команда и сколько времени занимает жизненный цикл задачи.Я рассмотрел время пяти основных этапов: в разработке (с момента создания задачи до ее отправки на проверку), ревью кода (происходит на стороне аутсорс-команды), деплое, тестировании и утверждении (на стороне сервиса).
, то есть мной).
В таблице указано количество дней, в течение которых задача находилась на каждом этапе разработки.
Несмотря на то, что в нашем случае над задачей одновременно работал только один специалист (разработчик, тестировщик или менеджер), эти данные не равны человеко-часам: задача висит в статусе, даже если над ней не ведется никаких работ. Я специально не показываю сбор требований, время ожидания релиза и прочие этапы, которые никак не отражают скорость работы команды.
За июнь правильно собрать статистику не удалось, поэтому этих данных нет в таблице.
По итогам работы за июль я заметил, что задачи больше всего времени находятся в трёх статусах: в работе, тестировании и проверке.
Проще всего было решить проблему длительного тестирования.
Тестировщик в нашей команде работал неполный рабочий день и просто не успевал оперативно тестировать все задачи.
Мы поговорили с подрядчиком и перевели его на проект на полную ставку.
Это сократило время тестирования вдвое.
Для базовых повторяющихся сценариев мы начали проводить автотесты в селене.
Это позволило нашему тестировщику быстрее выполнять регрессионное тестирование.
Мы сократили время заполнения анкет, без которых невозможно протестировать новый функционал сервиса.
Далее мы продолжили увеличивать количество автоматизированных тестов и улучшать показатели эффективности.
Во-вторых, я начал сталкиваться с задержками на этапе разработки.
При еженедельных итерациях я не мог позволить задаче зависать в течение пяти дней (весь спринт).
Перед финальным релизом мне хотелось хотя бы несколько раз увидеть функционал в действии.
Я решил проблему, разделив задачи на более мелкие.
По итогам августа мы отстали по показателю «Время на проверку» со стороны аутсорсинговой команды.
Поначалу я постоянно напоминал исполнителю, что он должен посмотреть код и дать комментарии.
В ноябре я передал эту ответственность тестировщику.
С этого момента, как только он заканчивал работу над заданием, он сам уведомлял об этом ответственного за проверку.
Полностью этот подход мы реализовали только в ноябре, когда развертывание на тестовом сервере стало занимать меньше времени.
В сентябре слабыми показателями были «Одобрение» сервисной командой и «Ожидание развертывания на тестовом сервере».
«Приемку» ускорили просто за счет более пристального внимания и быстрого реагирования на задания.
Более того, к этому времени процесс разработки уже вошёл в ритм, и на сопровождение у меня уходило не так много времени.
Время развертывания на тестовом сервере в сентябре заняло более 15% — это было крайне странно.
Оказалось, что после проверки задания последний исполнитель отправил его на тестирование.
Приходилось объединять ветки, иногда возникали конфликты, исполнитель отвлекался от текущих задач.
В октябре мы добавили механизм автоматической публикации задач в репозиторий, что значительно сократило время развертывания.
Потом мы доработали процесс и в итоге за два месяца сократили время развертывания в 8 (восемь!) раз.
В общей сложности за пять месяцев мы сократили время решения проблемы почти в четыре раза.
Раньше путь задачи от постановки до утверждения результата занимал в среднем 20 календарных дней.
Теперь, когда сроки сократились до пяти календарных дней, стало проще контролировать этапы разработки, оценивать окончательные сроки решения задач и планировать нагрузку команды.
Прогнозирование сроков
Еще одна важная задача – точная оценка сроков.По условиям договора с подрядчиком мне вообще было невыгодно попасть в оценку.
Если задача выполнялась быстрее, мы платили только за затраченное на нее время, а если команда не укладывалась в сроки, то платили меньше.
Но у меня были и другие причины искать точную оценку времени.
Например, скорость внедрения иногда влияет на выбор функционала.
Если на внедрение одной функции уходит день, а на реализацию другой — три дня, то менеджер, скорее всего, выберет тот вариант, который быстрее разработать.
При этом «однодневная» функция на практике может занять те же три дня, и если бы об этом было известно заранее, выбор вариантов мог бы быть другим.
Я посчитал процент точности, с которым каждый программист попадает в оценку.
В результате я получил коэффициенты, которые помогли мне точнее планировать сроки.
Например, если программист оценил задачу на 10 часов, но его уровень ошибок составляет около 40%, то я смело могу предположить, что задача займет 14 часов.
Выгода.
Сложность заключается в том, что ошибки в оценках сроков носят несистематический характер.
Программист может выполнять одни задачи в четыре раза медленнее, а другие — в два раза быстрее.
Это существенно усложняет расчеты и планирование.
Поэтому я посчитал не только среднее отклонение оценки сроков для каждого разработчика, но и процент отклонения от среднего.
Если оно было меньше 20%, я считал это хорошим результатом – такая ошибка в сроках не помешала мне планировать.
Но были отклонения и на 30%, и на 50%, и они сильно мешали работе над релизом.
Например, разработчик оценил срок в 10 дней, его стандартное отклонение от срока составляет 40%, поэтому реальный срок выполнения задачи становится 14 дней.
А вот если отклонение от среднего составит 50%, то это еще 7 дней работы над задачей.
В общей сложности срок работы составит 21 день вместо обещанных 10 и ожидаемых 14. С такими задержками работать невозможно, поэтому я постарался найти их причину и исправить.
В Jira я проанализировал задержки и их причины — пришел к выводу, что наибольшее отклонение от запланированного времени связано с задачами, которые не проходят мое одобрение и которые тестировщик возвращает несколько раз после тестирования.
Во-первых, я исправил ситуацию с заданиями из «приёмки».
Основная причина возврата заключалась в том, что тестировщик недостаточно проанализировал проблему.
Во время тестирования он действовал «по обстоятельствам», а иногда вообще не понимал, как должна работать функция.
Мы решили, что тестировщик подготовит для каждой задачи «Определение готовности» (DoD): не подробные тест-кейсы, а примерное описание того, что и в каком направлении он будет смотреть.
Я со своей стороны просматривал эти DoD и в случае ошибочного понимания или недостаточного тестирования сразу указывал на это тестировщику.
В результате количество возвратов с «приемки» сократилось практически до нуля, а сроки оценить стало проще.
Что касается частого возврата задач из тестирования обратно в разработку, то оказалось, что почти треть случаев связана с ошибкой при развертывании: например, не были запущены необходимые скрипты.
То есть опция вообще не работала, но это можно было понять и без помощи тестера.
Мы решили, что при развертывании задачи на сервере программист сам будет проверять простые скрипты, чтобы убедиться, что все характеристики работают. Только после этого задание поступает на проверку.
Эта процедура занимает не более пяти минут, а количество возвратов с тестирования снизилось более чем на 30%.
Для сложных задач мы решили провести совещание с разработчиком, тимлидом и тестировщиком.
Я прокомментировал документацию и подробно рассказал, что именно и как я хочу, чтобы это было реализовано.
Если на этом этапе команда разработчиков видела какие-то недочёты, мы сразу вносили изменения в документацию.
В таких случаях оценкой сроков занимались как минимум два человека — разработчик и тимлид. За четыре месяца средняя ошибка планирования снизилась в 1,4 раза.
Количество отклонений более 50% от средней ошибки уменьшилось с 9% до 1%.
Сбор и анализ статистики помог мне вовремя увидеть слабые места и исправить ошибки управления командой.
Некоторые из них могли случиться с «домашними» разработчиками, а другие были особенностью работы с аутсорсерами.
Надеюсь, принципы работы с внутренней статистикой будут полезны и вам.
Теги: #аутсорсинг #agile #cofoundit #startup #Управление разработкой #Управление разработкой #Управление проектами #agile #Разработка стартапов
-
Анализ Безопасности Маршрутизатора Smart Box
19 Oct, 24 -
Исправление Преобразований Лоренца
19 Oct, 24 -
Блокчейн: Что Нам Следует Обосновать?
19 Oct, 24 -
Агент Мониторинга: Простая Вещь Или Нет?
19 Oct, 24 -
Drush — Командная Строка Для Cms Drupal
19 Oct, 24 -
Time Warner Отказывается От Корней Aol
19 Oct, 24 -
Против Спама Всем Миром
19 Oct, 24
