Мы рады видеть сегодня с нами Елену Капитаненко, высококвалифицированного ИТ-эксперта с большим опытом работы в качестве руководителя проекта и аналитика бизнес-процессов, тренера в Svitla Systems, Inc., успешной компании-разработчике программного обеспечения с украинскими корнями. До своей нынешней должности Елена работала менеджером по обеспечению качества/бизнес-аналитиком в HotelFriend AG, известном стартапе в сфере гостеприимства, где она оттачивала свои навыки в тестировании мобильных приложений, веб-сайтов и систем управления отелями. Мы с нетерпением ждем возможности узнать больше о ее опыте и взглядах на мир ИТ.

Елена Капитаненко

Добрый день, Елена. Вы можете коротко описать базовые принципы проектного менеджмента без которых ни один проект не взлетит?

Для инициации проекта необходимо хотя бы базово понимать каждую грань нашего классического треугольника управления. 

а) Состав работ на разном уровне. Начинаем от целей проекта и хотя бы крупными блоками как они каскадируются на более мелкие технические, а что зачастую важнее, нетехнические работы.

б) Время. Какие у нас ограничения на различные фазы и как наладить цепь поставки таким образом, чтобы она была наиболее успешна. 

в) Ресурсы. Что нам нужно для того чтобы добиться целей? Деньги, возможности выхода на рынки, с помощью какой команды это реализовать, а прочее.

Для проектов в software engineering обычно есть дополнительные моменты, которые имеет смысл добавить в этот список и выделяющие ИТ-проекты из общие массы

г) Выбор подходящей управленческой методологии, в соответствии с потребностями проекта.

Чаще всего современные проекты несут в себе значительную часть инновационности, поэтому для создания программного обеспечения и для его поддержки выбирают методы и фреймворки из класса “гибких”, например Scrum или Kanban. Маленькие профессиональные высокомотивированные команды - основная единица структуры для создания успешных проектов. В наших реалиях такие команды также достаточно сомоорганизованы, кроссфунциональны и имеют существенную свободу в принятии решений, что является необходимым (но недостаточным) условием быстрой разработки
Также для крупных проектов, в которых задействованы от двадцати человек применяют их производные и надстройки, позволяющие обеспечить эффективную работу с применением “бережливого” производства и масштабирующие разработку с помощью SAFe, Nexus или LeSS до ~150 человек

д) Расширение определений классического “проекта” до “продукта” или сервиса.

Чаще всего чисто софтверная часть это большая, но не бОльшая часть продукта, и для успешного запуска бизнеса необходима плотная интеграция с продажами и маркетингом, аналитикой и финансами. Программисты могут быть отдельным департаментом в структуре компании, однако для проектов зачастую команды должны иметь регулярную и качественную коммуникацию с различными стейкхолдерами проекта. Таким образом продуктовая разработка и бизнес роллауты ведутся в плотном взаимодействии с командой разработки, в горизонтальных управленческих структурах для быстрой прямой коммуникации и быстрых циклов обратной связи) 

Важно применить подходы к выпускам, направленные на максимизацию количества управляемых экспериментов на те части продукта/проекта, которые содержат потенциально наибольшие выгоды и/или риски. Следовательно, выпуски/релизы для проектов зачастую должны делаться достаточно часто и регулярно, зачастую запуская А/Б/В тесты для разных сегментов пользователей на открытых или закрытых площадках. Также важно собирать действительно значимые метрики и отслеживать как те или иные изменения в проектах и продуктах позволяют добиваться целей

Какие самые распространённые ошибки в проектном менеджменте?

Самые распространенные ошибки в видимых мной проектах

а) Слабое целеполагание. Если “выход” из проекта либо инициативы не ясен, сложно как мотивированно выполнять проект, так поставить ожидаемую ценность. Как говорит классика, ‘Find Your Why’

б) Слабая команда, что чаще всего типично в больших компаниях. Принцип 20/80 прекрасно работает, и создание высокопроизводительной команды может перекрыть большинство проблем. Слабая же команда может потопить даже самую лучшую идею

Для маленьких команд в основном нужны “производственники” по Адизесу, хотя на каком-то уровне все компоненты PIAE должны присутствовать

в) Непонимание P&L и схем монетизации для коммерческих продуктов. Редко бывают проекты в которых ресурсы бездонны, и говоря про успешность необходимо хорошо представлять финансовую составляющую на различных фазах 

Какое программное обеспечение вы можете посоветовать?

Ой, смотря для каких целей, для какой экосистемы и под какой бюджет

Если мы говорим про проектное управление, то чаще всего мой набор таков:

1. Для целеполагания - Atlassian Confluence/Google Docs

2. Для визуализации чего угодно, в том числе целей и роудмапов - Miro/Mural. В них обязательно завести базовый пакет и правильно настроить приватность

3. Tasktrackers: JIRA/Trello/Monday, или те что интегрированы в текущиe CI/CD пайплайны (Azure, Amazon). Для маленьких команд можно использовать Basic пакеты

4. Чаты: Slack или то что удобно инфраструктурно

5. Конференции: Zoom. Нужен “про” аккаунт для больших и/или длинных конференций

6. ERP/CRM: Google tables с формулами и нужными вам интеграциями

Как стартапам с ограниченными ресурсами можно построить эффективную модель для контроля качества? 

Для стартапов качество удобно представить расширение треугольника Time-Scope-Resourses в пирамиду, путем добавления точки Quality в эту систему.

На разных стадиях стартапа эта пирамида будет выглядеть очень по-разному
а) Идея и прототип. Качество зачастую интересует только на “успешных путях”, то есть только на тех случаях где пользователи выполняют базовые сценарии. Так называемые “корнер кейсы”, съедающие до 80% процентов ресурсов и времени на разработку чаще всего игнорируются, если поведение системы не блокируется явным образом

б) Активная разработка и запуск. 

1. Планка качества обычно поднимается и уже нужно думать про применение нефункциональных видов тестирования. ISO и ISTQB определяю их более 20 ((UX, usability, performance, scaling…) и необходимо выбирать в зависимости от домена и условий те, что за минимальное время принесут максимальный результат. 

2. Необходимо включить соответствия регуляциям и законам в зависимости от рынка и сферы (GDPR, FDA, HARPA). Особенно зарегулированы сектора в здравоохранении и финансах, что обязывает включать дополнительные и существенные издержки на трассируемые QA и QC.

3. Резонно запускать закрытые бета-тесты как стадии, на которых и верифицируются бизнес гипотезы, и отлавливаются ошибки, которые воспроизводятся только в полевых условия

4. Часто имеет смысл привлекать специализированные и/или внешние команды для QC. Например, специалистов по кибер безопасности или нагрузочному тестирования для аудитов систем на пилотных стадиях

в) Первые запуски и последующая поддержка. На этих фазах наша пирамида уже опирается на полноценную сторону качества. К разнообразным превентивным практикам также добавляются методы сбора обратной связи от технических систем и пользователей и формируются каналы для ее обработки в зависимости от важности, влияния на бизнес и рисков. Формируются внутренние и внешние Servise Level Agreements (SLA) поддержки и разработки.

Какие книги, пособия вы могли бы порекомендовать?

1. PMBOK by PMI 

2. Scrum guide на www.scrum.org

3. Идеальный руководитель (Адизес)

4. Искусство пасти котов (Рейнвотера)

5. Дедлайн (Демарко)

6. От нуля к единице (Тил)

Далее это набор “технических” книг которые вам нужны будут именно в конкретном домене и тех.стеке. К примеру, если вы в Machine Learning - вам нужно понимать базовые принципы машинного обучения различных типов сетей. Без “специализирования” в тематике качественного управления не будет, по крайней мере на проектном и продуктовом уровнях.