Pull to refresh

Счастливый ProductOwner — верхом на пороховой бочке

Reading time 8 min
Views 1.8K
Вы — руководитель проектов и вам поручили создать сложный интернет-магазин с извращенным биллингом за 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 месяца, а за… год, остается :-)
Tags:
Hubs:
+65
Comments 34
Comments Comments 34

Articles