Обреченный на успех StartUp. Глава 5
Введение
В этой главе мы разберем проблему, которую отчаянно пытались решить, пожалуй, все менеджеры The StartUp: бизнес был недоволен качеством и скоростью разработки.
Почему из всех проблем, которую мы обсудили в Главе 4, была выбрана именно эта проблема? Она существовала в компании практически вечно и попытки её решения в The StartUp — это квинтэссенция всех других проблем.
Ссылка на предыдущие главы тут
Перед тем, как мы подробно погрузимся в проблему и методы ее решения, напомню, что взаимодействие владельца бизнеса с командой выглядело так: бизнес передавал задачу, а менеджер, присутствующий на встрече, уходил с ней к команде.
Реальность команды
Что происходило в команде после появления новой задачи от бизнеса?
В команде существовал Roadmap с задачами от бизнеса и продактов команды, баги и технический долг. По умолчанию новая задача отправлялась в очередь после предыдущих задач от бизнеса, так как те были уже были нарисованы, учтены в архитектуре, и разработка по ним вот-вот должна была начаться.
То есть новая задача проходила следующий путь: через несколько дней она попадала к дизайнерам; через несколько недель — к аналитикам, через несколько месяцев — в разработку. После этого: 1–3 недели на разработку, тестирование, приемку операционной командой.
И вуа-ля! — задача попадала на прод спустя полгода.
Неоправданные ожидания бизнеса
А как же для бизнеса выглядел этот черный ящик, в который попадала его задача?
Новая идея передавалась команде, и, поскольку до этого команда «ничего не делала», она тут же бралась за задачу. Но вуа-ля, разработка занимала полгода!
Через полгода бизнес и менеджеры встречались на демо. И у бизнеса был закономерный для его картины мира вопрос: «Почему задача делалась полгода?»
Ответы варьировались в зависимости от того, кто из менеджеров был на демо: «Разработка долго делала», «Дизайнеры долго рисовали», «Аналитики не могли выбрать решение».
Бизнес был недоволен, готов был уволить представителей той команды, которая на встрече не присутствовала и соответственно была виновна. Встреча заканчивалась долгими обсуждениями, руганью и новыми задачами, которые нужно было сделать «вчера».
Но что забывали обсудить на таких встречах? Какой срок ожидал бизнес? С какого момента этот срок отсчитывался?
Новый подход: сроки от менеджера
После нескольких таких неприятных разговоров бизнес понял: комфортнее обсуждать сроки с CTO. Он был спокоен, умен и разделял ценность бизнеса — работать по 25 часов в сутки.
CTO озвучивал: «Это займёт неделю». Бизнес рад, что фича будет готова через неделю. CTO рад, что бизнес доволен.
Оставалось сделать так, чтобы “дизайн + проработка + разработка + тестирование + приемка” заняли неделю.
Сколько раз за 5 лет получилось это сделать? Правильный ответ найдете в нашей новой книге: “Ровно 0”.
Почему же сроки, озвученные СТО, не выполнялись
- Не был учтён Roadmap: задача не оказывалась первой в списке (last in — last out).
- Разработка оценивалась не с исполнителями, которые знают нюансы архитектуры и кода, а менеджером, который сам не пишет код.
- Не было учтено время на проработку до и тестирование после разработки.
Игнорирование этих факторов позволяли краткосрочно порадовать бизнес, а долгосрочно снова попасть на демо, где бизнес недоволен сроками и кто-то в этой жизни неправ.
Но команда постепенно осознавала все проблемы и находила решения.
В оценку надо было включить всех участников процесса
Первое, что предстояло понять, учесть и донести до бизнеса, что между передачей задачи и релизом существуют промежуточные звенья.
Дизайнеры. С ними было проще всего, результат их работы для бизнеса был очевиден, его можно было посмотреть глазами.
Аналитики и архитекторы. Они должны были придумать, как бы эта новая фича не развалила уже работающий продукт. Объяснить, что делают они было сложнее.
Самым убедительным аргументом для бизнеса стал опыт аутсорс-разработки, где аналитики и архитекторы отсутствовали, и всё было жутко неприспособленным к изменениям, к тому же даже СТО был не готов от них избавиться.
QA-инженеры были самым непонятным и постоянно вызывающим полнейшее недовольство фактором. “Почему вообще надо что-то тестировать? Почему разработчики сами не тестируют? А самое интересное — уже если тестируют, то почему все равно есть баги."
Короткий аргумент был такой: “пробовали без куашников, качество было плохое”.
Постепенно, лично знакомя бизнес с представителями каждого подразделения, удалось убедить его в важности командной работы и в необходимости учитывать работу всех в оценке.
Примерно через год после первой нереалистичной оценки СТО начали учитываться все этапы разработки. Это был прорыв: бизнес понял, что команда разработки состоит не только из разработчиков.
Но первоначальная проблема осталась. Сроки всё равно не выполнялись.
Оценки должны озвучивать исполнители
Оценки — это тема достойная дискурса и мы его проведем в отдельной статье. Здесь мы принимаем как данность: бизнес начал спрашивать оценки и их нужно было давать.
В культуру проекта постепенно начала входить практика оценки задачи разработчиками-исполнителями. То есть ребята смотрели на дизайн, архитектуру и аналитику, декомпозировали задачи и оценивали сроки реализации. По умолчанию работа других членов команды принималась за константу: в среднем на продуктовую документацию, действительно, тратилось постоянное время.
Да простит меня наша команда, но это был совершенно дивный процесс, как в фильмах: все сидят у компьютеров, задают друг другу перекрестные вопросы, пытаются понять, что из себя представляет эта фича. Для меня, как для продакта это было очень мило, потому что “я не несла ответственности за эти циферки в WBS”, — думала я до первого раза, пока не стала одним из тех менеджеров, который стал ответственный “за всё.”
В итоге появлялись прелестные детализированные WBS; бизнес мог сразу понять, где можно сократить сроки или затраты; команда получала ясность по задачам.
Иногда в оценке были указаны конкретные люди, потому что мы знали, что Сережа лучше всех разберется с приколами Safari.
Но держим в голове, дорогой читатель, что такая качественная оценка, сама по себе была сложной задачей. Она занимала время и, соответственно, стоила денег. А иногда на оценку уходило больше времени, чем на реализацию.
Но бизнес требовал оценки, и команда давала ему то, что удовлетворяло его потребности.
Частично такая качественная оценка, конечно, решала проблему сроков: у бизнеса больше не было иллюзии, что задача попадёт на прод через неделю. Кроме того, некоторые фичи меняли свой изначальный облик, потому что оказывались слишком дорогими.
Постепенно детальная оценка стала рутиной и вошла в культуру проекта.
Заключение
Внимательный читатель заметил, что мы не обсудили проблему с Roadmap. Сделали мы это намеренно, потому что неумолимо следуем тайм-лайну. Проблема RoadMap — не совпадающие приоритеты бизнеса и команды, дошла до команды позже. Вот поэтому и разберем мы ее в последнюю очередь - как раз в следующей главе.
А специально для тех, кто снова все дочитал, здесь я подготовила RoadMap следующих глав (там же можно найти ссылочки на предыдущие), чтобы вы понимали, а что еще захватывающего вас ждет.