Счастливый ProductOwner — верхом на пороховой бочке
Вы — руководитель проектов и вам поручили создать сложный интернет-магазин с извращенным биллингом за 4 месяца. Вам хочется работать в этой компании ближайшие 2-3 года — платят хорошо, проекты громкие. Топы верят в вас. На кону ваша профессиональная репутация.
Разберем, какой оседлать собственное подразделение разработки и добиться успеха.
Процесс
Если у вас есть полномочия и достаточно энергии — используйте Agile/Scrum в негуманной редакции. Если дело пойдет не туда — можно довернуть гайки и перейти в облегченный RUP, добив коммунизм ядерным ударом. Сейчас некогда разводить бюрократию и писать ТЗ на 1000 страниц.
Что делаем?
Нужно собрать требования по проекту. Быстро и основные. К сожалению, большое количество людей в компаниях в нашей стране, как правило — профанируют занимаемые должности. А умных людей, к счастью, подавляющее меньшинство. Если будете задавать профильным специалистам вопросы в лоб о том, как устроен их рабочий день, который интернет-магазин должен автоматизировать — приготовьтесь побороть желание придти на работу с бейсбольной битой и начать крошить тунеядцев.
Не советую задавать прямые вопросы руководителям отделов — наживете себе злейших врагов — еще бы, вы открываете тайну, что сотрудники в их отделах… не знают чем занимаются :-)
Если вам так не повезло, ищите любыми способами адекватного аналитика для сбора требований и охраняйте его жизнь. Постарайтесь найти поддержку у топов. Не найдете — увольняйтесь.
Иногда в компании все же удается собрать требования к проекту.
Сводим воедино
На базе собранной информации делайте несколько артефактов чрезвычайной важности:
1) Глоссарий. Это слово = значение. Если его не сделаете, не сможете дальше общаться с «умными» сотрудниками из отделов, не сможете понять аналитика и вас не поймет разработка, в которую скоро пойдем.
2) Логическая модель данных — это квадратики-слова из глоссария и показанные отношения между ними (1 — *, * -*, 1 — 1). Данный инструмент проходят наши дети в школе сейчас при изучении логики. Самое сложное — расставить правильные отношения и выявить сущности.
3) Прототипы интерфейсов. Отрисуйте с аналитиком от руки или от ноги прототипы страниц веб-сайта. Без деталей.
4) Если дело пошло и вам и аналитику все понятно — выявите роли и их действия. Просто в табличке перечислите. Если не пошло — не беда.
Ахтунг. Самое сложное — нужно свести все воедино. Тратим 1-2 полных дня. Можно на стене, доске. Происходит чудо — вы увидите основные части системы целиком. Если сами не увидите — постарайтесь, чтобы увидел аналитик, дайте ему премию :-). Это очень важно.
Теперь нужно постараться, чтобы эксперты из других отделов увидели то же самое и согласовали с вами логическую архитектуру системы. Звучит смешно и глупо. Но иногда везет Да, люди будут включать дурачка, делать вид что не оканчивали школу… — вранье, любой человек способен описать термины, связи между терминами и свою роль в общей системе. Помогите им в этом, подключите топов :-)
Если вам повезло и удалось заставить людей задуматься, возможно впервые в жизни — отправьте аналитика в отпуск, он заслужил.
Планируем релизы
Логический позвоночник продукта вы увидели — это 50% успеха. Дальше дело техники. Идем к разработчикам. Распределяем фичи на сложные/средние/простые с заранее определенной средней оценкой каждой категории.
Если фич больше пятисот — включайте в команду второго аналитика, иначе сойдете к черту с ума и сведете туда же разработчиков.
Программисты значительно лучше оценят фичи, если увидят прототипы интерфейсов, глоссарий, лог. модель данных, роли и задачи. А этом мы сделали.
Не рекомендую проводить шоу под названием StoryMapping — если только в ваши задачи не входит развлекать людей и создавать атмосферу тусовки. Инструмент с размазанной формальностью думаю подходит только для простых систем или… гигантских систем.
Самые приоритетные фичи включаем в первый релиз. В результате получаем грубый план релизов проекта. Объявляем жесткую дату запуска каждого релиза и проекта в целом.
Специальные релизы
Настоятельно рекомендую включить одним из окончательных этапов проведение нагрузочного тестирования на тестовых данных. Иначе можете запустить проект, а он… загнется через 2-3 дня.
Еще очень полезен релиз качества — проводится комплексное бета-тестирование внутри компании. Снова проверяем весь функционал.
Выбираем точку отсчета
Важный момент. Вам нужно определиться и принять обоснованное решение:
Пишем с нуля
Если ваша задача — прокачать программистов, рекомендую писать проект… с нуля :-). Если вам нужно запустить интернет-магазин через 4 месяца — забудьте этот пункт как страшный сон.
Правда если пойдете по этому пути — станете другом программистов вашей команды, будут здороваться с вами в коридорах. Еще бы — дали людям такую возможность прокачаться :-)
Пишем с «единицы»
Начальник разработчиков (если он прячется за командами, найдите его обязательно — такой в компании всегда есть) может предложить сократить время разработки за счет использования «низкоуровневого» фреймворка. Для PHP их несколько: ZendFramework, Yii, Symfony, CakePHP…
Выбираем или нет? Дам совет — если пишите уникальную сложную систему, обрабатывающую большие объемы данных и обслуживающую миллионы посетителей в сутки (типа FaceBook ;-)) — выбирайте низкоуровневый фреймворк, не пишите с нуля. ZendFramework — как раз рассчитан на энтерпрайз класс задач.
Дело в том, что опытных программистов очень и очень мало, особенно в нашей стране, а низкоуровневые фреймворки пишут как раз такие люди, поэтому не рискуйте и используете их наработки.
Вашими друзьями станет примерно вторая половина команды разработчиков, т.к. они понимают, что можно немного прокачаться и на фреймворке. Первая половина — потеряна для вас.
Но наша задача — за 4 месяца запуститься :-) Поэтому фреймворк нас скорее всего не спасет.
Пишем на базе коробочного решения
Тут первая ключевая задача — понять, как работает коробка и ложиться ли ее логика в вашу задачу создания интернет-магазина с извращенным биллингом. Рекомендую разобраться самому и заставить разобраться аналитику. Если окажется, что подходит — вам повезло.
Вторая ключевая задача — убедиться, что команда разработки сможет на базе коробки сделать вам проект в срок. Если коробка имеет хорошую техдокументацию и систему бесплатной/платной сертификации разработчиков и можно обучить людей работе с ней за две-три недели — шансы на успех значительно возрастают.
Большой минус — разработчики скорее всего перестанут с вами здороваться. Им придется работать и решать четкие бизнес-задачи путем доработки ЧУЖОГО кода — а это очень бьет по мотивации начинающего программиста. Все хотят творить реальность самостоятельно :-)
Выбор коробочного решения… Если у вас очень сильная и опытная в ООП команда разработчиков, со средней зарплатой по москве в районе 100к и в команде человек эдак десять — для навороченного магазина неплохо подойдет Magento.
Если же вы ограничены в ресурсах и сроках (3 разработчика, 3-4 месяца) и ожидаете, что кроме функциональности интернет-магазина скоро или уже требуется обеспечение технической поддержки клиентов, сервисы опросов, форумы, блоги, встроенный поиск, интеграция с 1С, поддержка российских платежных систем, если хотите после запуска проект САМОСТОЯТЕЛЬНО через админку управлять сайтом, не привлекая программистов для малейшего изменения функционала — тут разумеется коробка от 1С-Битрикс вне всяких конкурентов. Вы запуститесь в срок и ближайшие 2-3 года будете плевать в поток — управляя сайтом через админку без привлечения разработчиков.
Более того, если вы не хотите ругаться с командой разработки по поводу «почему стал тормозить интернет-магазин, клиенты жалуются» или «почему интернет-магазин вчера не доступен был с 9 до 11 утра» :-) — СРАЗУ создавайте проект по типу веб-кластера — благо в вышеупомянутой коробке есть такая возможность.
Программисты вашей команды взвоют от использования любой коробки и устроют вам темную :-) Мне помогал такой фокус — для самореализации программистов я просил сложные задачи делать на базе крутого низкоуровневого фреймворка, например ZendFramework. В итоге и овцы оставались целы, и волки сыты.
Делаем спринты
В ваших шкурных интересах — качество выполненных за спринт фич. Из-за отсутствия жесткого водопадного цикла контроля качества вы рискуете нарваться на быструю разработку фич фекалийной консистенции.
И не думайте, что если будете долю времени в спринте тратить вместо реализации фич на написание командой юнит-тестов, это спасет вас от погружения в болото безобразного качества. Юнит-тесты нужно УМЕТЬ писать, а найти таких людей — сложно.
Если не хотите тестировать выпущенный в спринте сырой функционал по ночам и на выходных — постарайтесь сделать всё, чтобы разработка тщательно проверяла то, что она делает перед демонстрацией. За качество каждого спринта перед вами персонально отвечает руководитель отдела разработки или техдир — команда, как мы помним, это коллективное бессознательное и не за что не способна отвечать (люди приходят и уходят и алименты не платят, а нянчится с проектом придется вам).
Если вы не удовлетворены качеством спринта — дергайте рубильник и останавливайте гов… но конвейер. Собирайте совещание и разбирайте причины выявленных проблем с руководителем разработки/техдиром — с командой вопросы качества на ретроспективах обсуждать как правило бесполезно, зря потратите время.
Качество — это системный, а не эмоциональный процесс. Задачу нельзя решить на том же уровне, на котором она возникла. Пока не будут приняты системные меры в разработке: настроен трекер, внедрено Continuous Integration и т.п. — дальше не идете, спринт не принимаете, конвейер стоит.
К сожалению, иногда приходится воевать на тему качества с разработчиками — и требовать кадровых перестановок в команде и менеджменте разработчиков.
Иногда можно добиться создания отдела тестирования и потребовать пропускать выполненные спринты через него. Бейтесь и добьетесь.
Нагрузочные спринты
Для контроля того, что проект будет работать с ожидаемыми объемными данными, после реализации крупной фичи в серии спринтов — проведите ее нагрузочное тестирование, не откладывая на потом. Если окажется, что система висит и не обрабатывает ожидаемый объем данных — собирайте совещание с рук. разработки/техдиром и устраивайте разбор полетов. Пока не будут приняты системные меры — конвейер остановлен, спринт не принимается. Опять таки — такие системные задачи, как качество архитектуры и программирования — плохо решаются на уровне ретроспектив. Решайте на более высоком уровне.
Аналитик — ваш друг
Поручите аналитику тщательно проверять, что поставленные на спринт в фичах и дополнительно прокомментированные в логической модели данных, прототипах интерфейса и глоссарии требования — выполнены в полном объеме, как продуманно и написано. К сожалению, часто приходится тащить и доделывать ДО КОНЦА КАК НАПИСАНО фичи из одного спринта в другой.
Фиксируйте время, потраченное на «доделку» фичи, связанную с невнимательным чтением описания требования. Если процент безалаберности в команде возрос до критического уровня — ищите руководителя разработчиков/скрам-мастера и… бейте — это его задача обеспечить дисциплину в командах.
Экспериза оценок
Может случиться так, что в команде все дружно начнут завышать оценки на PlanningPoker — это выгодно программистам, т.к. можно не торопиться и делать работу в размеренном темпе, попивая кофеек. Правда, это не выгодно вам. Поговорите с экспертом в области разработки — техдиром (если еще не успели испортить с ним отношения :-)) — если его оценки ниже даваемых командой, вам не повезло :-) — рекомендую в этом случае отказаться от PlanningPoker и оценивать их самому, на базе предыдущих оценок и накопленного вами к этому моменту опыта — согласовывая порядок оценок с экспертом, которому доверяете. Вариантов не остается.
Корректировка процесса
Чем хороши гибкие методологии типа Scrum — так это открытостью процесса. Если не получается и проект заваливается — это видно всем, видно хорошо. Может оказаться, что:
— разработчики в команде оказались слабыми и неопытными
— скрам-мастер оказался тряпкой, лидера в команде нет, тусение и раздолбайство, которое выражается в недочитывании требований до конца, халтуре и многочисленных багах
— технический директор скрывается от вас, считая что ваша задача заниматься воспитанием программистов :-)
Можно закрутить гайки в направлении упрощенного RUP:
— С аналитиком пишите ТЗ на итерацию
— Оцениваете ТЗ с руководителем отдела разработки/техдиром
— Разработка тщательно тестирует своими силами результаты итерации, демонстрируя успешное выполнение юнит-тестов (хотя бы на момент приема работы)
— Тщательно принимаете выполненную работу, вам помогает в этом также аналитик
Да. Это будет уже война капитализма с коммунизмом. Но шанс победить и запустить интернет-магазин, правда не за 4 месяца, а за… год, остается :-)