В статьях об управлении продуктами часто пишут о разнице между продакт- и проджект-менеджер — наверно, потому что звучит очень схоже. Если вы смогли в этом разобраться, то вот вам другая задача, со звёздочкой: понять разницу между менеджером продукта (он же продакт-менеджер, product manager, PM) и владельцем продукта (продакт-оунер, product owner). Вопрос непростой, тем более что в некоторых компаниях предпочитают объединять эти роли, вручая все обязанности одному человеку. Можно ли так делать и в чём разница, разбираемся вместе с куратором программы курса Project Manager Дмитрием Васиным.

Кто чем занимается

Если вкратце, продакт-менеджер — лицо, которое принимает окончательное стратегическое решение по продукту: по его видению, стратегии, бизнес-цели. А владелец продукта — это роль в методологии Scrum, ответственная за достижение максимальной ценности продукта.

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

Продакт-оунер несёт ответственность за достижение максимальной ценности продукта — как результата работы команды. И добивается он этого при помощи Scrum — фреймворка гибкой разработки программного обеспечения. Владелец продукта понимает, кто чем занимается в команде, управляет бэклогом, плотно взаимодействует с разработчиками и другими заинтересованными лицами. Он отвечает за то, чтобы все члены команды имели ясное представление, над чем работают и в какой последовательности будут выполнять задачи.

Почему возникает путаница

Scrum — простая структура, ориентированная на помощь командам в разработке программного обеспечения. Она не охватывает общие практики управления продуктами: разработку стратегии, составление дорожной карты и финансовый прогноз. Единственный инструмент управления, который предлагает этот фреймворк, — приоритизация бэклога.

Есть подходы, где разделяют роли продакт-менеджера и продакт-оунера, чтобы облегчить масштабирование. Например, SAFe — Scaled Agile Framework — фреймворк для координации работы над проектом (или связанными проектами) для пяти и более скрам-команд. Владелец продукта в SAFe — не то же самое, что продакт-оунер в Scrum, так что это только добавляет путаницы. Зачем тогда в Scrum вообще введена роль владельца продукта? Почему бы в фреймворке не использовать термин «менеджер продукта»? 

Дело в том, что в 1990-х годах, когда был разработан Scrum, управление продуктами отличалось от сегодняшнего. Менеджеры продукта делали предварительные исследования рынка, планировали выпуск продуктов и определяли требования к ним. Затем они передавали спецификацию и требования менеджерам проектов, которые и занимались созданием продуктов. Затем менеджеры продукта возвращались только для того, чтобы поставить задачу на внесение правок или помочь на этапе запуска.

Сейчас, при гибком управлении, все работает совсем иначе. Сотрудники, создающие продукты, должны постоянно взаимодействовать с командами разработчиков, не пренебрегая рынком и внутренними заинтересованными сторонами.

Сегодня Scrum применяется за пределами сферы разработки: в банках, ритейле, медиакомпаниях. Эти организации приняли такую систему, но у них традиционно нет команд по управлению продуктами и, следовательно, менеджеров. А диджитал-продукты есть: приложения для онлайн-банкинга, программное обеспечение для автоматизации бизнес-процессов, повышения производительности и снижения затрат.

Чтобы начать работать гибко, в этом случае достаточно ввести должность продакт-оунера (владельца продукта). Scrum позволяет возложить эту роль на кого-то из команды — так что не придётся создавать целую группу управления продуктами и инициировать организационные изменения. Сотрудники бизнес-подразделений после обучения и инструктажа смогут выступать в качестве владельцев продуктов. Но в долгосрочной перспективе полезно выделять эту функцию отдельно.

На практике термины «менеджер продукта» и «владелец продукта» часто используются как взаимозаменяемые. Однако специалисты не играют одну и ту же роль под разными именами — это две уникальные функции. Сравним рабочие задачи:

Может ли продакт-оунер быть менеджером продукта?

Наверное, будет вечно продолжаться дискуссия о том, где заканчивается одна роль и начинается другая. Как и о том, действительно ли эти функции — просто два аспекта одной и той же должности.

Короткий ответ: да, владелец продукта может быть менеджером продукта — и наоборот. А если это всё-таки два разных специалиста, то крайне важно, чтобы они понимали, чем различаются их роли и обязанности.

Можно пройти международный двухдневный тренинг, чтобы называться владельцем продукта. Но проблема в том, что потом человек занимает должность менеджера по продукту — и не имеет ни малейшего понятия, что делать. Он на самом деле не понимает всего объёма своих обязанностей и не знает, как добиться успеха в работе.

Управление продуктом — это многогранная дисциплина, которую трудно освоить. Чтобы эффективно выполнять роль менеджера продукта, нужно быть лидером и уметь управлять жизненным циклом продукта, составлять его стратегии и исследовать рынок, формировать бизнес-модели и работать с финансовыми показателями.

Материалы для дальнейшего изучения

• Руководство по Scrum — исчерпывающее описание правил игры, ролей, событий, практик и ценностей. Это первое, с чего нужно начать изучение фреймворка.
• Product Manager vs Product Owner — статья одного из совладельцев компании Silicon Valley Product Group Марти Кегана. Он участвовал в разработке многих успешных продуктов, был старшим вице-президентом по управлению продуктами и дизайном в eBay, а до этого — вице-президентом в AOL и Netscape Communications, инженером-программистом в HP Labs.
• Описание ролей в SAFe — информация о гибком фреймворке, который позволяет использовать Agile-методологии в больших командах (от 50 человек).

Менеджер продукта — увлекательная профессия, освоить которую можно на факультете GeekUniversity. За 14 месяцев обучения вы вместе с дизайнером и командой разработчиков создадите свой продукт и на собственном опыте узнаете о множестве нюансов работы продакт-менеджера.

На связи технический директор Calltouch Роман Хохлов. Роман несколько лет исследовал методологию управления процессами в компании. За это время он сформулировал перечень базовых элементов организации командной работы, и в этой статье Роман готов поделиться своими наблюдениями.

Информация о том, что такое эффективность управления будет полезна управленцам, руководителям и координаторам любых организационных структур. Это ни в коем случае не рецепт успеха. Скорее, компетентная оценка базовым процессам управления командой. Каждый найдет в статье свою пользу. Новичкам – это предостережение на будущее. Специалистам – помощь в работе. Руководителям – целостная методология эффективного управления организацией. 

Командообразование

За любыми процессами разработки и производства продуктов стоят люди. Приступая к управленческой работе, вам придется учитывать возможности своей команды. Эффективность работы напрямую зависит от вашего умения выстраивать взаимодействия внутри коллектива. Если умеете – команда продуктивно трудится. Не умеете – всё идет вразнос.

Основные проблемы и барьеры

Слабые звенья. Первая причина – в команде собраны неравноценные специалисты. Вторая – участники не задействуют свои сильные стороны. В любом случае коллективный процесс спотыкается о человеческий фактор.

Непонимание масштабов. Группы из 5, 25 и 100 человек – это совершенно разные структуры. У каждой такой команды свое восприятие целей и условий их достижения. Если руководитель не учитывает законы развития своей группы, начинаются перекосы. Например, механизмы, свойственные крупным компаниям, внедряются в малые коллективы. Обратный пример, попытки сплотить десяток департаментов корпорации через тимбилдинги.

Пассивность и застой. Однотипные задачи неуклонно сужают кругозор и навыки сотрудников. Рутина снижает мотивацию. В итоге, коллектив теряет интерес к проектам. Расширяйте компетенции сотрудников в команде. Например, дайте им возможность перемещаться между проектами и дисциплинами. Конечно в рамках разумного, без ущерба основной деятельности.

Практический опыт решения

Два года назад перед компанией встала задача оптимизации процессов. Начали с кадров.

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

Второй шаг. Ротация. Оказалось, что некоторые разработчики лучше справляются с задачами, от которых были удалены длительное время. Мы перенаправили одного способного программиста с багфиксинга на передовую разработки. Что это дало? За 2 месяца создали модуль распознавания пола по звонкам и заявкам. Один из мощных и передовых в экосистеме Calltouch.

Ротация – это незаменимый инструмент, который помогает:

• выявить сильные стороны сотрудника;
• получить сотруднику ценные навыки из смежных направлений;
•  повысить вовлеченность сотрудника в общий процесс.

Здесь мы подходим к вопросам масштаба и личной составляющей процессов. В нашем коллективе численностью до 20 человек мы можем себе позволить:

• сплоченную команду с сохранением человеческого отношения в рамках структуры;
•  ежедневные митинги целым отделом, где каждый имеет право слова;
•  вникать в полный спектр продуктов и услуг компании;
• создавать вовлеченную команду в процессе разработки продукта. Изначально вокруг проекта создается очаг – ключевые сотрудники. Рядом с ними обозначается эпсилон-окрестность вовлеченности. В неё попадают сотрудники из других проектов по правилу ротации.

Разрастаясь, проект постепенно выходит на взаимодействие целых отделов. Перемещаются и взаимодействуют уже не только люди, но и команды.

Усложнение системы – это новый вызов для управленцев. Необходимо внутри микрогруппы сохранить здоровые отношения и рабочий настрой. То есть работа команд должна напоминать взаимодействие людей, но только в большем масштабе.

Что следует помнить:

• Есть интерес сотрудника – найдется работа для него. Отсутствие навыков не проблема – научим. Нет интереса сотрудника – извини, нам не по пути.
• Сотрудник – не узкоспециализированная машина. Он хочет, может и должен учиться новому.
• Процесс обучения и взаимопомощи – это естественная возможность повысить сплоченность коллектива, компетентность сотрудников. 
• Необходимо учитывать основы групповой динамики. Для компаний разного размера работают свои принципы постановки и достижения целей.

Механика рабочего процесса. Приоритизация задач

Закончив с командообразованием, руководителю следует обратить внимание на следующий метод эффективного управления - механику процессов. Как и откуда задачи поступают в отдел? По какому регламенту они выполняются? Что с ними происходит далее?

Основные проблемы и барьеры

Отсутствие планирования. Без четкого плана и приоритетов, команда выполняет задачи несогласованно. Как результат – нестыковки в проекте, хаос в работе сотрудников. В нашем случае можно выделить три источника задач:

• Продакт-менеджеры формируют задания на разработки новых или улучшение существующих продуктов.
• Техподдержка работает с жалобами пользователей. Собирает информацию о неполадках и передает на исправление разработчикам.
• Повестка отдела разработки по созданию и модернизации продуктов/процессов.

Осложняется работа тем, что техподдержка физически располагается во Владимире, а разработка – в Москве. Возможности быстрого согласования процессов ограничены. Кроме того, излишняя активность менеджеров мешает разработчикам. Зачастую предложения по доработкам затмевают поток основных задач.

Отсюда проистекают попытки сделать всё и сразу. Без серьезного планирования и расстановки приоритетов. В итоге от такой работы получается скоп недоделанных модулей и критических ошибок.

Разрывы между этапами проекта. Когда плана совместной работы нет, возникают перекосы в командном процессе. Например, группа разработчиков закончила свой объем работы. Она уже готова передать эстафету коллегам, но те завязли в параллельном проекте. Через несколько недель они принимают фронт работ первой команды. Тратят несколько дней, чтобы вникнуть в суть задачи. Только после этого включаются в работу.

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

Бесконечные итерации. Когда у руководителя нет внятного плана работы над проектом, страдает вся команда. Сотрудникам ставятся неверные приоритеты, даются беспорядочные указания. Разработчикам подкидывают новые «хотелки» менеджеров раз в час. В итоге проект буксует.

Не менее опасно отсутствие разумных ограничителей итераций. Например, масштабную задачу невозможно решить без подзадач и промежуточных итогов. Не разбитая на кусочки «глыба» вызывает в команде стресс и неопределенность. А это срывает сроки и тормозит другие проекты. 

Практический опыт решения

Как мы поступили.

Разгребли мусор. Первым делом – прибрались в багтрекере. Процесс разработки прилично ускорился. Со стороны казалось, что мы налегли на новые разработки, забросив работу над ошибками. Всё ровно наоборот. Драйвером роста стало то, что мы избавились от груза ошибок.  

Мы приняли SLA, согласовали его с техподдержкой. Теперь отвлекаемся только на критические неисправности. Задачи с меньшим приоритетом ожидают решения, не мешая основному процессу. Зачастую баги вписываются в текущую итерацию проекта и быстро устраняются.

Обозначили свои возможности другим отделам. Далее – договорились с продакт-менеджерами о соблюдении четкого алгоритма взаимодействия. У нас есть свой четкий распорядок. Доработки без критического статуса – терпеливо ждут очереди.

Процесс разработки подчиняется концепции таймфреймов:

• Совместно с продакт-менеджерами составляем квартальный план. В документе прописываем идеи с высоким приоритетом и перечень задач.
• Рабочий процесс делится на недельные спринты.
• Ежедневные митинги помогают держать друг друга в курсе происходящего. Общаясь командами, мы можем изменять вектор развития.

В итоге, разработка концентрируется на приоритетных задачах на определенный срок. При этом сроки не являются чем-то жестким и неоспоримым:

•  Ценность спринтов в том, чтобы сориентировать разработчика по предстоящей итерации. Нам важно не загнать всех под дедлайн, а дать панорамную картину процесса.
• Лучше взять меньше задач и по мере выполнения добрать новых. Мы решили не брать на себя больше, чем можем выполнить за определенный отрезок времени. Такой подход дал результат. Мы перестали распыляться и сфокусировались на узком круге задач.

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

За счет расширения компетенций сотрудников, мы выстраиваем гибкий процесс. Разработчики трудятся без надрыва и с удовольствием. С другой стороны каждый сотрудник всегда занят в каком-либо процессе. Закончился один этап, разработчика по правилу ротации переключают на другой проект.

Культура и концепция управления

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

Думайте своей головой. В Calltouch мы не стали слепо копировать популярные практики AGILE. Вместо этого мы взяли базовые принципы SCRUM и дополнили их собственными наработками. В итоге получили гибкую методологию управления, которую можно подстроить под уникальные случаи.

Забудьте про KPI. Здесь важно соблюдать меру. Не нужно отказываться от измеримости бизнеса. Напротив, эффективно управлять без измерений результатов невозможно. Но любые измерения должны быть адаптивны и соответствовать реальности.

Помните, что неадекватные показатели эффективности вредят рабочему процессу. Стараясь выполнить KPI, сотрудник может потерять мотивацию к работе и на длительный период времени выпасть из процесса. В то же время, творческая обстановка и поддержка позволит ему без всяких показателей перевыполнить все нормы.

Важнее создать рабочий продукт, чем следовать канонам. Вызовы рынка слишком многогранны, чтобы зацикливаться только на «правильных» решениях. Если диаграммы burndown и ведение бэклога важнее креативных идей, то стоящих продуктов не создать.

Нет явных оценок времени и трудозатрат. Вместо жестких дедлайнов, мы управляем изменениями. Самоорганизация и быстрая реакция помогает нам корректировать процессы на ходу. Например, завтра разработчик Фёдор под настроение зафиналит проект, на который отводилась неделя. А Пётр вдруг заболеет и не выдаст новое обновление в срок. Тогда остальные участники подхватят буксующий процесс. Так или иначе, на выходе мы получим рабочий продукт точно по графику.

Сталкиваясь с такими обстоятельствами, мы моментально их просчитываем. Далее просто встраиваем изменения в повестку дня и используем с выгодой.

Результаты

За первый год мы улучшили на 80% показатели планирования сроков. Согласно статистике в JIRA:

• В июне 2017 закрыто 96 багов, 85 тасков
• В июне 2018 закрыто 99 багов, 147 тасков
• В июне 2019 закрыто 105 багов, 213 тасков 

До анализа данных, нам казалось, что ошибок за год стало меньше. Но JIRA свидетельствует об обратном.

• Это обусловлено возросшим количеством новых продуктов. Однако в пересчете на один продукт багов стало меньше.
• Мы разгребали «мусор» багов за прошлый год.
• Приоритизация приносит свои плоды. Мы четко поняли, в каком порядке работать с ошибками. Стали устранять баги быстрее.
• Базовые меры по командообразованию позволили повысить качество исполнения проектов.

На текущий момент, устранение багов занимает один день в неделю из пяти.    

В бэклоге значительно уменьшилось количество задач по сравнению с первым годом. Если в 2017-м там было более 350 задач, то в 2019-м их около 180. При этом оба года наблюдается рост компании. Мы выпускаем больше продуктов.

Для сравнения. По состоянию на 2 квартал 2017 года мы не выполнили ничего, чтобы стабильно работало. За 2 квартал 2018 году создали около 30 новых задач различной степени сложности. Одним из драйверов успеха стала работа продакт-менеджеров. Они стали заблаговременно прорабатывать и ставить задачи, что сильно улучшило общий процесс.

Как видим, много внимания мы уделили процессам и культуре управления проектами. Но важно понимать, что 80% успеха компании – это люди. Все зависит от того, насколько вы успешно соедините задачи компании с ценностями и интересами сотрудников.

GeekBrains продолжает рассказывать о методологиях разработки программного обеспечения. Если вы еще не читали предыдущие тексты о методологиях «Водопад», Scrum и XP, бережливой разработке и Kanban — самое время наверстать упущенное!

Сегодня мы рассмотрим методологию, которую успешно применяет один из самых мощных IT-гигантов — компания Microsoft. Это Microsoft Solutions Framework, или MSF. С ее помощью создано большинство современных решений и проектов «Майкрософт». 

Ты помнишь, как все начиналось

История создания MSF берет начало в 1993 году. Компания Microsoft уже была ведущей в IT-сфере и искала способы повысить эффективность и отдачу от своих проектов.

90-е годы стали временем расцвета новых подходов к разработке. Модель «Водопад», которую использовали больше двух десятилетий, уже в полной мере не отвечала требованиям в IT: была слишком жесткой и формализованной, медленно реагировала на новые потребности пользователей.

У Microsoft был обширный опыт в создании программных продуктов и продвижении масштабных IT-проектов: были уже выпущены Windows 3.11, Office 3.0 и многое другое. Компания суммировала накопленные знания и навыки, проанализировала опыт конкурентов и в 1993 году выпустила серию руководств, посвященных организации труда разработчиков — «белые книги» MSF. 

Пять лет спустя, в 1998, была выпущена вторая ревизия MSF. В 2001 за ней последовала третья, а в 2005 вышла последняя на данный момент версия — MSF 4.0.

Отличительными чертами Microsoft Solutions Framework стали гибкость и масштабируемость. Эта методология подходит для работы в проектной группе или организации любого масштаба. MSF включает основополагающие принципы, модели и дисциплины управления персоналом, процессами и технологиями. Другим преимуществом методологии стала ее демократичность и отсутствие иерархических отношений «начальник — подчиненный». 

Основополагающие принципы MSF

Принципов, на которых базируется MSF, всего восемь. 

Способствуйте открытому общению
Модель MSF предусматривает свободный и открытый обмен информацией между всеми членами команды и заинтересованными сторонами. Это помогает исключить недопонимание между заказчиком и исполнителем и снижает вероятность того, что работу придется переделывать. Все этапы разработки обстоятельно описываются, обеспечивается доступность документации для всех участников проекта — так налаживается эффективное взаимодействие.

Работайте над общим видением
Данный принцип Microsoft Solutions Framework подразумевает, что все члены команды должны детально понимать цели и задачи, над которыми работает коллектив. Общий взгляд на то, каким должен быть результат, гарантирует, что усилия разработчиков будут согласованными.

Зачастую к успеху приводит именно умение правильно понять и сформулировать достоинства выработанного решения. Кроме того, эффективность труда в команде повышается, когда все сотрудники видят картину проекта в целом. Это стимулирует их интересоваться даже теми областями проекта, которые не относятся непосредственно к их задачам. Благодаря этому сотрудники глубже вникают в принципы работы программного продукта, обмениваются идеями и решениями, помогают друг другу и нарабатывают новые компетенции и командный опыт. 

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

Разделяйте ответственность
Все участники проекта принимают и осознают свою ответственность за порученную задачи и собственные решения.

В MSF проект делят на равноценные и уникальные сегменты. За успешную реализацию каждого в равной степени отвечают все специалисты, работающие над ним. Участник подотчетен своей рабочей группе, она — всей организации, а та, в свою очередь, — заказчику. При этом ответственность распределяется на каждом уровне равномерно между всеми сотрудниками.

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

Сотрудничайте с клиентом и сосредоточьтесь на предоставлении бизнес-ценности
Всегда нужно помнить о главном: программное решение должно представлять ценность для бизнеса заказчика. MSF требует от команды ориентироваться на клиента и вовлекать его в работу.

В MSF  это значит понимать его цели и проблемы: зачастую заказчик совсем не разбирается в разработке программного обеспечения или даже в компьютерах, но это не мешает ему быть экспертом в своем бизнесе. Только он знает точно, каковы его потребности; какая функциональность жизненно необходима, а какая избыточна; что имеет ценность для бизнеса, а что — нет. Поэтому необходимо, чтобы клиент был вовлечен в работу над проектом, и если он доволен результатами — все идет как надо.

Будьте готовы к переменам и оставайтесь гибкими
Любая разработка программного обеспечения требует времени. Это означает, что на каком-то этапе работы требования заказчика могут измениться — к этому стоит быть готовыми.

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

Инвестируйте в качество
Успех команды зависит от того, насколько каждый специалист осознает свою ответственность за продукт. Чтобы обеспечить высокое качество решения, на протяжении всего проекта работает группа тестирования — в ее задачи входит раннее выявление ошибок и недочетов. Обнаруженные баги надо исправлять как можно скорее, чтобы они не повлияли на разработку. Microsoft Solution Framework требует, чтобы в планы и графики изначально вносилось время на устранение недостатков. Только в этом случае можно уложиться в срок.

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

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

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

Пять «белых книг» MSF

MSF разработана как комплекс отдельных компонентов — моделей и дисциплин. Всего их пять, и они описаны в пяти «белых книгах» (white papers) MSF. 

Моделей используется две:

• модель команды;
• модель процесса.

А дисциплин в MSF три:

• управление проектами;
• управление рисками;
• управление готовностью.

Рассмотрим их.

Модель команды MSF

Команда разработчиков — главный стратегический ресурс компании, определяющий успех проекта. В традиционной практике команды организованы иерархически — от руководителя до работников низшего звена, например:

Пример традиционной иерархической организации труда

При такой организации работы вес мнения отдельного сотрудника определяется не его компетенциями и знаниями, а положением в иерархии. MSF предлагает более демократическую модель команды, и поэтому не испытывает проблем классической. 

Команда проекта в MSF — это коллектив равноправных сотрудников. Они разделяют ответственность и свободно обмениваются опытом и информацией. Внутри команды есть ролевые кластеры (роли), отражающие функциональные обязанности конкретных специалистов. У каждой роли — свои цели и задачи, и все они считаются равноценными и одинаково важными. Роли дополняют друг друга и вместе служат единой цели — созданию качественного продукта.



Модель команды в MSF

Эту модель можно масштабировать для работы как крупных компаний, так и небольших коллективов.

Примеряем роли

Бизнес-аналитик
Это главный посредник между командой разработчиков и клиентом. Он должен детально разобраться в потребностях заказчика, определить бизнес-ценность продукта и понять, какая именно функциональность необходима в программе. Он трансформирует эту информацию в конкретные определения и требования к качеству и доводит их до разработчика. Можно считать, что бизнес-аналитик — представитель клиента в коллективе. Он управляет продуктом, чтобы тот соответствовал потребностям бизнеса и ожиданиям заказчика. 

Менеджер проекта
В модели MSF главная задача менеджера проекта — контролировать график работ и бюджет. Он отвечает за то, чтобы все задачи выполнялись своевременно и не выходили за пределы сметы. Занимается планированием работы и составляет отчеты, оценивает риски и вырабатывает меры по их снижению. Тесное сотрудничество с другими ролями проекта позволяет ему быть в курсе событий и оперативно решать административные проблемы. 

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

Разработчик
Кажется, что роль разработчика — самая незатейливая. Рабочая лошадка: создает код и воплощает идеи клиента, трансформированные в техническое задание усилиями бизнес-аналитика и архитектора. И придерживается сроков, установленных проект-менеджером. 

Но в MSF разработчик — полноправный участник всех обсуждений. Он определяет, какое время потребуется ему для создания функциональных блоков программы. Помогает архитектору выстраивать удачную структуру проекта с точки зрения его реализации, основываясь на своем глубоком знании языка программирования. Участвует в создании дизайна приложения. В проекте считается экспертом по всем техническим вопросам, и за ним зачастую остается последнее слово в совещаниях о том, «как все это реализовать в рамках используемых технологий». 

Тестировщик
Задача тестировщика — выявить в продукте баги, проблемы и неудачные решения, которые могут негативно сказаться на качестве и снизить ценность приложения для клиента. Тестировщик обязан понимать и учитывать контекст применения программного продукта: кто, как и для чего будет его использовать на стороне заказчика. Если функция X выполняется корректно и выдает правильный результат, но его получение занимает в среднем час, тестировщик может признать ее работу неудовлетворительной — зная, что клиенту требуется выполнять эту функцию 20–30 раз в день. 

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

Релиз-менеджер
В Microsoft Solutions Framework, что касается выпуска готового продукта или любой его работоспособной версии, — на релиз-менеджере. Он создает план выпуска версий, сертифицирует готовый продукт и следит за тем, чтобы программа дошла до клиента. Кроме того, в его обязанности входит информационное сопровождение версий, например описание новых функций, изменений и нововведений. 

Администратор баз данных
Если в составе продукта есть база данных, то команде не обойтись без администратора БД. Он следит за порядком в базе, ее целостностью и состоянием данных, работоспособностью серверов. В его обязанности входят все рутинные операции, обеспечивающие безопасность и сохранность информации, например регулярное создание бэкапов.

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

Несмотря на множество ролей, модель MSF подходит не только большим коллективам, но и маленьким командам: в этом случае каждый участник берет на себя несколько ролей. 

Методология MSF подчеркивает, что все роли — равноправны, и ни один член команды не может считаться более влиятельным или принимать решения единолично.

Модель процесса MSF

Еще один важный компонент методологии MSF — модель процесса, то есть последовательность действий, необходимых для построения IT-решения. Модель не предписывает конкретных процедур и не содержит жестких формализованных требований к процессу — при создании MSF компания Microsoft стремилась сделать ее гибкой и адаптируемой к условиям любого проекта. В MSF объединились две концепции разработки: «Водопад» и спиральная модель. 

От «Водопада» MSF досталась система вех (milestones) — особых точек в конце каждой фазы процесса, отвечающих заданным критериям завершения фазы. В этих точках команда рассматривает результаты своего труда и отвечает на вопросы «Сделали ли мы все, что планировали?», «Работает ли решение так, как нужно заказчику?», «Готовы ли мы двигаться дальше или необходимо уделить внимание доработкам?». Чтобы перейти на следующий этап, необходимо дать большинство положительных ответов.

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

Тем не менее MSF — это не просто компиляция двух систем. Инновационность методологии заключается в том, что она охватывает жизненный цикл решения от начала проекта до развертывания в реальном времени. Это помогает проектным группам сосредоточиться на бизнес-ценности приложения, поскольку она не будет реализована до тех пор, пока решение не развернуто и не запущено в эксплуатацию.

Весь процесс разработки в MSF разбит на отдельные итерации. Каждая проходит несколько этапов (фаз).



Модель процесса MSF

1. Выработка концепции (Visioning)
Команда вырабатывает единое видение проекта или его части. Совместными усилиями коллеги решают, какая именно функциональность будет разрабатываться в ходе итерации, определяют основные концепции, которые лягут в основу разработки. Этап завершается вехой «Концепция утверждена».

2. Планирование (Planning)
Задачи, которые необходимо выполнить в ходе итерации, разбиваются на подзадачи, определяется сложность их реализации, устанавливаются сроки и назначаются ответственные. В планы закладывается время на тестирование и исправление дефектов, а также предварительно намечается, как именно будет проходить тестирование.

3. Разработка (Developing)
На данном этапе MSF создается программный код новой функциональности в соответствии с концепцией и утвержденными планами.

4. Стабилизация (Stabilizing)
К делу подключаются тестировщики. После тестирования выявленные баги и недочеты возвращаются разработчикам для исправления. 

5. Внедрение (Deploying)
Очередной релиз программного продукта передается заказчику и устанавливается на клиентских компьютерах. 

В конце каждой итерации клиент должен получить работоспособную версию приложения. По завершении этапа внедрения и итерации в целом немедленно начинается новая итерация. 

Дисциплины MSF

Управление проектом

В MSF это целый набор навыков и компетенций, в том числе:

• комплексное планирование всех этапов и аспектов проекта;
• управление бюджетом, расходами и ресурсами;
• подготовка графиков и контроль за их соблюдением;
• ведение административной документации.

Роль, ответственная за выполнение этого сегмента работы, — менеджер проекта (программы). По мере того как масштаб проекта растет, управление проектом может разделиться на две специализированные ветви: одна будет связана с архитектурой программного решения и спецификациями, а другая — собственно с управлением проектом. 

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

MSF стремится избавиться от иерархической структуры. Поэтому и при управлении проектом нет диктатуры. Демократичные обсуждения, при которых рассматриваются все точки зрения и достигается консенсус, способствуют выработке наиболее удачных решений. Когда члены команды не могут прийти к соглашению, менеджер проекта выступает арбитром: он обязан принять решение, максимально удовлетворяющее клиента и ориентированное на его бизнес-ценности.

Управления рисками

Риски — это факторы и события, которые могут оказать негативное влияние на проект в перспективе. В MSF есть специальный процесс, который помогает выявлять, отслеживать и минимизировать риски. Он состоит из шести шагов.



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

2. Анализ и расстановка приоритетов
Насколько серьезную угрозу представляет выявленный риск для проекта? Возможно ли избежать проблем? Требуются немедленные действия или время терпит? Необходимы ли дополнительные ресурсы, например время на поиск решения?

Все эти вопросы обсуждаются коллегиально. 

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

4. Отслеживание и отчет
Придерживаться принятого плана неукоснительно — половина дела в MSF. Любое изменение в проекте может повлечь новые риски или рецидив старых. Отслеживание рисков помогает держать их под контролем и своевременно пересматривать тактику борьбы с ними.

5. Контроль
Контроль — это исполнение планов в отношении рисков и связанных с ними отчетов. 

6. Знание
Изучая риски, команда получает новую информацию о них и о способах преодоления сопутствующих сложностей. Эти знания необходимо фиксировать и помещать в базу данных, чтобы иметь к ним доступ в будущем. 

Управления готовностью

Эта дисциплина занимается вопросами профессионального роста и подготовки специалистов.

С точки зрения организации, знания и навыки сотрудника — это ценный ресурс, так что обучение и повышение квалификации можно рассматривать как улучшение качества ресурса. В MSF под готовностью понимается отношение текущего объема знаний и навыков к тому уровню, который желателен или необходим для конкретного специалиста. От готовности зависит, например, способность сотрудника выполнять ту или иную роль в команде.

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

Процесс управления готовностью включает четыре этапа:

1. Определение
На этом этапе выстраивается структура команды. Для каждой роли определяются уровни квалификации и компетенции, необходимые для успешной работы специалистов. Кроме того, вырабатываются сценарии — типичные виды деятельности, которые потребуются для разработки проекта. 

2. Оценка
Здесь внимание сосредоточено на каждом члене команды. Проводится анализ компетенций и навыков, связанных с должностными обязанностями, и определяется, насколько они соответствуют желаемым показателям для каждой конкретной роли. Это позволяет выявить разницу между текущим уровнем знаний и требуемым. В результате можно разработать планы индивидуального обучения для каждого сотрудника, которые позволят ему приобрести нужный уровень компетенций. 

3. Изменение
В процессе обучения специалисты совершенствуют знания, чтобы преодолеть разрыв между нынешним и желаемым уровнем квалификации. При этом используются учебные планы со списками ресурсов и учебных материалов — учебников, технических документов. Учебный план может предусматривать и самостоятельное изучение, и под руководством наставника.

4. Подведение итогов
На этом этапе проводится повторная оценка знаний и компетенций, чтобы определить, были ли планы обучения эффективными и не требуются ли дополнительные занятия. Рассматриваются не только теоретические знания, но и способность сотрудника использовать их на практике. 

Управление готовностью — процесс, в идеале не завершающийся на протяжении всего проекта. Непрерывное совершенствование знаний и умений каждого члена команды — путь к повышению качества и успешности проекта в целом. 

В заключение

Пять «белых книг» описывают MSF в мельчайших деталях, давая точные определения ее компонентам, а также подробные описания процессов. 

Тем не менее методология MSF остается гибкой и может легко масштабироваться для использования в корпорациях или стартап-проектах. Она очень демократична по своей сути, но категорически требует одного — отказаться от иерархии и диктатуры в управлении. Любое решение должно быть выработано в коллективе коллегиально, а ответственность распределяется между всеми. Кроме того, MSF поощряет постоянный обмен информацией и накопление коллективного опыта, а также подталкивает каждого члена команды к совершенствованию знаний и повышению квалификации.

Методология не требует применять специализированные средства компании Microsoft. Существуют системы, «заточенные» под MSF, например Visual Studio Team System — и Microsoft прямо призывает организации, использующие ее, следовать MSF. Но ничто не мешает применять MSF с любыми другими средствами организации производства.

Microsoft Solutions Framework используется уже более четверти века, помогая компании Microsoft разрабатывать новые решения и развиваться. И это аргумент в пользу методологии.

Первая продажа и выход на прибыль — два сакральных момента для основателя стартапа. И когда вы только начинаете, выйти «в плюс» обычно кажется чем-то за гранью реальности, а впервые продать продукт — осуществимой, но мечтой.

Сегодня поговорим о том, как сказку сделать былью и дойти до первой продажи с нуля и найти клиентов для стартапа. Я знаю три способа: выпуск минимальной версии продукта, продажа «обещаний» и краудфандинг. Все я опробовал на своем сервисе «Скорочтец», так что теперь расскажу об их действенности и достоверности — то есть о том, насколько первые продажи, полученные данным способом, неслучайны и являются показателем будущего стабильного спроса на продукт.

Выпуск минимальной версии продукта (MVP стартапа)

Это способ, что называется, в лоб. Очевидно же: хочешь продать — сделай продукт и продай! Но программисты часто затягивают разработку продукта и не могут его выпустить.

Например, когда я задумал «Скорочтец», пошел на курс по продвинутой fullstack-разработке, а потом около недели размышлял, как бы мне организовать шардирование базы данных. Сейчас это кажется просто смешным, ведь спустя год на моем сервисе чуть более тысячи зарегистрированных пользователей. Короче, чуть-чуть не дотягиваю до нагрузок Instagram.

Думаю, вы поняли. Не размышляйте о нагрузках, сверхархитектуре, выборе «правильных» языков и фреймворков — лучше здраво содрогнитесь, что у вашего проекта еще нет ни одного пользователя. Сделайте минимум того, что задумали, и дайте людям. Сделайте это как можно быстрее!

Другая распространенная ошибка — желание сразу все формализовать: оформить ООО или ИП, договоры между членами команды и прочее. Здесь работает тот же принцип: делайте все очень просто и очень быстро. Например, можете составить договор в свободной форме и подписаться под ним всей командой. И не спешите платить налоги, ведь вы еще ничего не заработали.

Мой опыт первых продаж MVP

Мы с напарником начали писать сервис «Скорочтец» в феврале 2018 года, а к концу июня уже была готова основная функциональность: программа курса с пятью уровнями, все упражнения (пусть недоработанные и с багами), мобильная верстка. Кстати, напарник за это время сменился.

Полноценно запустились мы 27 июня, а 3 июля случилась первая продажа. Пользователь пришел из статьи на Habr, написал об ошибке, а я отблагодарил его промокодом с большой скидкой. Результат не заставил себя долго ждать.

Моя оценка

Скорость: 1 / 5. MVP — это самый медленный из способов. Даже в простом продукте придется потратить 3–6 месяцев, чтобы дойти до продажи.

Достоверность: 5 / 5. Зато самый достоверный. Абсолютно незнакомый человек заходит на сайт и покупает — какой эксперимент может быть чище? В случае сервиса «Скорочтец» достоверность подтвердилась десятком продаж за месяц после первой покупки.

Продажа «обещаний» в стартапе

Речь идет о продаже еще не созданного продукта. Вы делаете кнопочный прототип, текстовое описание, гифку, видео, презентацию — короче, что угодно, что даст людям ясное представление о вашем продукте. Затем просите деньги вперед и только потом делаете сам продукт и даете пользователям.

Как вы понимаете, самое сложное здесь — обеспечить доверие. Делайте это любыми человеческими способами: продавайте знакомым людям (это не грех), пришлите свой паспорт, позвоните человеку, встретьтесь лично.

И не бойтесь! Если даже у вас ничего не получится, вы просто вернете людям деньги.

Самая большая неожиданность способа в том, что «обещания» продаются намного легче минимальной версии продукта. Если задуматься, это логично. Обещания идеальны: в них нет багов, они показывают не только минимальную версию, но и продукт в перспективе. В конце концов, люди покупают лично у вас в живом общении, а не у бездушного сервиса, что тоже играет роль.

Но есть и подвох: если «обещания» раскупили на ура, это не значит, что готовый продукт будут покупать так же. Реальных покупок может и не произойти, пока сам продукт не дорастет до уровня обещаний.

Мой опыт

Осенью того же 2018 года я задумал еще один продукт. Вместо курса скорочтения — читалка, в которой текст исчезает, так что пользователю некогда отвлекаться на перечитывание и он начинает читать быстрее.

Я быстро собрал прототип, сделал гифку с демонстрацией и отправил пользователям «Скорочтеца». Потом лично написал всем заинтересованным — 12 из 24 перевели мне деньги! Безумие!

Но штука в том, что пользователи представляли себе читалку по качеству ничуть не хуже, чем у «ЛитРес». Кроме того, я «обещал», что, возможно, мы создадим алгоритм, который будет автоматически генерировать вопросы по прочитанной главе (до сих пор хочу это сделать).

И поэтому, когда появился реальный продукт — читалка не самого высокого качества с единственной необычной функцией исчезновения текста, — никто ее не покупал.

Продажи начались, только когда я интегрировал читалку в основной сервис, так что люди смогли загружать свои книги и учиться скорочтению на них.

Моя оценка

Скорость: 5 / 5. Это самый быстрый способ: всего неделя и первые деньги в кармане!

Достоверность: 2 / 5. Но не совсем достоверный. Ваше личное общение с людьми, идеальность обещаний и малый размер выборки сильно загрязняют эксперимент.

Краудфандинг и стартап

Краудфандинг — это институционализированная продажа обещаний. Здесь вы тоже рассказываете, обычно с помощью видео и текстового описания, что хотите сделать. Люди, которым нравится придуманный вами продукт, дают деньги, и только потом вы его делаете. Отличие в том, что происходит все на специальной платформе.

Может показаться, что платформа приведет вам больше покупателей, но это не так. Она скорее обеспечивает доверие к вам со стороны незнакомых людей. А вот привлечь их должны вы сами. Как это сделать, описано здесь.

Вы можете столкнуться с тем, что краудфандинг пройдет на ура, но «чистые» продажи затормозят. С одной стороны, вероятность этого невысока из-за большего количества людей, а с другой — к краудфандингу всегда примешивается нотка благотворительности, что хорошо в ходе кампании, но никак не после ее завершения.

Мой опыт

В марте 2019 я задумал создать книжные марафоны на основе сервиса «Скорочтец» и попутно прокачать читалку. На этот раз решил попробовать краудфандинг. Подготовка заняла около трех недель: я активничал в соцсетях, создал видео и текст.

Вы можете посмотреть, что получилось. Длительность кампании составила 36 дней. И в итоге она не завершилась успехом: собрано лишь 9 500 рублей из запланированных 250 тысяч. Немногие спонсоры, которые поддержали проект, больше интересовались текущим продуктом. Так что я сделал вывод, что книжные марафоны не востребованы пользователями, и пока не буду их реализовывать. И это тоже результат: представьте, сколько времени и сил сэкономлено!  

А вот читалку я все же не удержался и прокачал.

Моя оценка

Скорость: 3 / 5. Не очень быстро: 2–4 недели на подготовку и месяц самой кампании по сбору средств.

Достоверность: 3 / 5. На мой взгляд, достоверность выше, чем у ручных продаж, из-за большего размера выборки. Но тут накладывается эффект благотворительности и упомянутая идеальность обещаний.

На офисной кухне или в курилке невольно слушаешь разговоры коллег о том, зачем и почему они «все это» делают и как донести до всех причастных важность нашей работы. Как доказать, что мы не тратим время других сотрудников и деньги компании впустую, а занимаемся действительно важными вещами? Ведь часто думаешь, что ты делаешь самую нужную и крутую фичу, которую все ждут.

И у вас такое было? Тогда вам будет интересно.

Вся наша работа, по сути, сводится к поочередному выполнению задач. Поэтому их приоритизация чрезвычайно важна.

Методов и алгоритмов приоритизации очень много. Каждому этапу развития, на котором находится ваша компания, может подойти один из них. Возможно, в данный момент приоритизация задач вам вовсе не нужна. Если вы работаете с проектами, где понятна последовательность выполнения задач и ресурсы в полном вашем распоряжении, — скорее всего, вам это не пригодится.

О приоритизации

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

В каждой организации по-своему распределяются ресурсы. Бывают команды с общими — и ограниченными — ресурсами: несколько менеджеров могут задействовать в разработке одних дизайнеров, программистов, аналитиков. В таком случае начинается борьба за них: на общих митингах надо быстро и достоверно (на цифрах) обосновывать, почему именно твою фичу, а не коллеги, должны взять в будущий спринт.

О важном

Обычно у компании есть цель, к которой она глобально стремится, — а значит, все выполняемые задачи должны приближать к ее достижению. Цели могут быть долгосрочными — они описаны в стратегии, — и краткосрочными, которые изложены, например, в roadmap’е на несколько месяцев. Но не стоит забывать: на каком бы уровне цели ни находились, они всегда связаны друг с другом. И наши задачи всегда должны следовать вектору глобальной цели. Если это не так, задайте вопрос «почему?» и, предлагая гипотезу, обязательно сверьтесь с целью бизнеса.

Можно просчитывать затраты на разработку вплоть до подсчета ROI по каждой цели, прибыли с нее или потерь, если ее не достичь. Другой вариант — не углубляться, а просто разбить цели на четыре категории: «не принесет прибыли», «принесет мало», «даст среднюю прибыль», «обеспечит большую прибыль». Меры «много» и «мало» вы устанавливаете сами.

Приоритизация задач в несколько шагов

Шаг 1

Сначала рассмотрим способ, который поможет отбросить ненужные гипотезы.

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

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

Потом приходит время для следующей, более глубокой приоритизации.

Шаг 2

Посмотрим, какие существуют инструменты приоритизации:

• RICE;
• ICE Score;
• Kano;
• WSJF;
• GIFT.

Разберем один из них — RICE. Это метод приоритизации гипотез по разработке фич. Расшифровка названия:

• Reach — охват;
• Impact — влияние;
• Confidence — уверенность в вашей оценке охвата, влияния и трудозатрат;
• Effort — трудозатраты.

Чтобы получить оценку по RICE, необходимо следовать следующему алгоритму приоритизации.

(Reach*Impact*Confidence)/Effort=Score

Reach — показывает, сколько пользователей будут применять новую функциональность. Посмотреть это можно по системам веб-аналитики, по прошлому опыту или по конкурентам.

Например, представим, что вы ставите баннер в новом формате на главной странице сайта, посещаемость которой — 10 000 уникальных пользователей в месяц. Получается, именно столько людей увидят вашу фичу. Если вы взяли месячный период, то используйте его при рассмотрении всех гипотез. Учитывайте это и тогда, когда начнете считать Impact в денежном выражении.

Impact — это величина, характеризующая влияние вашей фичи. В идеале ее нужно представлять в денежном эквиваленте, так как для бизнеса это понятнее всего. Но часто останавливаются на субъективной оценке.

Confidence — чтобы понять этот фактор, задайте себе вопрос: как быть уверенным в своих действиях? Правильно: подкрепить их.

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

Перечислим часто используемые и известные способы подкрепления:

• UX-исследования;
• опросы;
• интервью;
• наблюдения;
• MVP;
• A/B-тесты;
• сторонние исследования;
• аналитика;
• и другие пользовательские исследования.

Не нужно забывать, что помимо результатов качественных и количественных исследований есть более простые доводы, почему вашу фичу должны взять в работу. Среди них:

• собственные убеждения;
• мировые тренды;
• мнение команды, эксперта, руководителя;
• «все конкуренты делают это», «продукт не работает без этого».

Еще важные каналы информации:

• топ обращений в саппорт;
• топ запросов от сейлз-менеджеров;
• топ запросов от клиентов.

В итоге у нас сформировался перечень способов, как подкрепить гипотезу. Этот список с расставленными весами привел в удобный вид Itamar Gilad — продакт-менеджер Gmail и YouTube ☺. Рекомендую почитать его блог — https://itamargilad.com/.

Как видите, если гипотеза — это только ваше мнение, то у нее минимальный вес. Поэтому прежде чем что-то отдавать в разработку, подумайте, как проверить, насколько необходима эта фича, и сможете ли вы сделать ее с минимальным вовлечением программистов. Ведь все мы знаем, что самые большие затраты уходят в фонд оплаты труда разработки.

Effort — оценивается либо в часах разработки, либо в story point — это не меняет сути. Всегда можно привести к одной шкале.

В целом это все. Теперь можно заносить данные в таблицу, фильтровать по наибольшему значению Score и брать в работу.

Пример таблицы Score

Для каждого из параметров необходимо задать свою шкалу баллов. Рассмотрим это на примере Reach. Предположим, самую маленькую фичу могут увидеть/использовать 100 K уникальных пользователей, а самую крутую — 1 000 K. Берем 10-балльную шкалу и переводим наши значения:

Из таблицы видно, что гипотеза 2 наиболее приоритетна, — ее и нужно брать в работу первой.

Все это нужно, чтобы:

• сфокусироваться на главных задачах;
• обеспечить прозрачность работы;
• мотивировать команду.

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

Чтобы вы понимали, кто и чему учит на новом курсе продуктовой аналитики в GeekBrains, мы подготовили «панорамный» обзор специальности: задали вопросы кураторам каждого из пяти учебных блоков. Хотелось показать вам детализированную и объемную картину: какие темы и инструменты изучат студенты за четыре с половиной месяца.

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

Unit-экономика, аналитика продукта и бизнес-метрики

Елена Чернышева — 10 лет работает с разными видами B2B- и B2C-продуктов в сфере мобильной и веб-разработки, а также сбора данных. Участвовала в создании продукта для FMСG-производителей и торговых компаний, перезапустила сервис «Яндекс.Справочник», развивала B2C-направление сервиса «Яндекс.Недвижимость». Сейчас — product-менеджер «Яндекс.Шеф».

— Елена, привет! Первый вопрос о профессии продуктового аналитика: что он делает на практике, что должен уметь и какими инструментами владеть?

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

Основное, чем занимается продуктовый аналитик:

• собирает и готовит данные для анализа;
• автоматизирует обработку данных и другие рутинные задачи, которые съедают время;
• создает инфраструктуру, которая позволяет клиенту самостоятельно готовить отчеты;
• проводит исследования, анализирует метрики, изучает поведение пользователей;
• строит и проверяет гипотезы;
• и главное — находит точки роста для бизнеса.

Если работа выстроена правильно, аналитик не отвлекается на повторяющиеся задачи.

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

В блоке продуктовой аналитики мы выясним, как перевести цели бизнеса в конкретные цифры и выстроить систему метрик. Как исследовать поведение пользователей и на этой основе находить места для улучшения в продукте. Что делать, если данных нет или недостаточно. Я покажу, как проверять гипотезы с помощью A\B-экспериментов и не только.

В других блоках курса студенты освоят инструменты аналитика, такие как Power BI и Python.

— Любому ли бизнесу нужны такие специалисты? Где они востребованы прежде всего?

— Любому бизнесу, который относится к тому, что он делает, как к продукту, или хочет перейти на такой подход. В России product-менеджеры и аналитики есть в штате 75 % самых богатых компаний Рунета по версии Forbes. Продуктовую аналитику берут на вооружение даже компании, которые больше про офлайн: ВТБ, Сбербанк, ПИК и другие.

Кстати, на западе многие продуктовые подходы впервые появились именно в производственных офлайн-компаниях и лишь позже пришли в IT. Например, метод OKR (Objectives and Key Results). У нас в стране, наоборот, — офлайн-компании перенимают практики у онлайновых.

— Есть ли смысл идти на эту специальность жителю маленького города?

— Там тоже есть бизнесы, но скорее эта профессия востребована в городах с населением более 500 тысяч человек. Я из Калининграда — там можно найти работу и не хватает таких специалистов.

— Это сугубо офисная работа? Аналитик должен постоянно находиться в гуще событий?

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

Сейчас появляется все больше распределенных команд, и устроиться на удаленку аналитик в принципе может, но не так легко, как программист. Этот путь потребует дополнительных знаний и навыков. У человека должна быть хорошая математическая подготовка или техническая база — как компенсация за более долгое погружение в бизнес.

— Какими личными качествами, на твой взгляд, важно обладать аналитику?

— Любопытством, интересом к тому, что тебя окружает. Аналитик похож на исследователя, который выясняет то, чего мы раньше не знали или не замечали. Плюс важно уметь мыслить системно, чтобы видеть структуру.

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

— Сколько длится твой блок и какие практические проекты сделают студенты?

— В блоке восемь занятий, на которых будут практические задания двух типов:

1. Подробно разбираем известные сервисы.
2. Студенты тренируются на своих проектах или чужих сервисах, которые сами выбрали.

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

Маркетинг, веб- и мобильная аналитика

Дмитрий Баланин — 10 лет в маркетинге и аналитике для рынков России, Германии и Китая. Развивал performance marketing и аналитику в «Эльдорадо», Яндексе и OneTwoTrip. Сейчас — CEO Room42.ru и CEO Differture.com.

— Дмитрий, твой блок — хронологически первый в программе — закладывает фундамент для дальнейшего изучения профессии. Почему студентам так важно вначале познакомиться с основами маркетинга?

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

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

За четыре недели занятий мы со студентами на примерах разберем, как решать задачи, которые ставят перед аналитиком маркетинг и другие заказчики: внутренние и внешние.

А еще мы подробно рассмотрим инструменты для исследования рынка, анализа сайтов и мобильных приложений, организации A/B-тестирования.

— Будут ли реальные кейсы? И какие проекты выполнят слушатели за время обучения?

— Курс целиком построен на практическом опыте: моем и компании, где мы уже реализовали более 150 аналитических проектов.

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

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

Презентация данных и аналитическая культура в компании

Евгений Малахов — 5 лет в разработке продуктов, маркетинге и аналитике. За последние два года реализовал более 100 аналитических проектов, в том числе для Pepsico, Philip Morris, KIA, Газпром. COO проекта Room42.ru. Победитель пяти всероссийских конкурсов по бизнес-проектам.

— Евгений, чему конкретно учит блок, посвященный презентации данных?

— Этот блок помогает студентам взаимодействовать с командой, правильно объяснять и преподносить результаты своей работы, подстраиваться под меняющиеся условия, в которых приходится выполнять задачи.

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

— Какие конкретно инструменты и методы нужно изучить, чтобы правильно преподносить свои результаты? И есть ли в учебной программе реальные кейсы?

— Да, мы разбираем материал на реальных примерах. Главное, чему я научу студентов за две недели:

• смотреть на проблемы и задачи с позиций бизнеса;
• смотреть на проблемы и задачи с позиции дизайнера, разработчика, таргетолога, подрядчика и любого другого участника команды.

По итогам занятий студенты:

1. Сделают презентацию для менеджмента, где обоснуют внедрение сквозной аналитики в компании.
2. Подготовят документацию для разработчиков и рекламщиков.

Аналитик — тот человек, который наглядно объясняет всей команде (от руководства до разработчиков), какие цели наиболее приоритетны, на какие метрики ориентироваться в данном проекте и почему сейчас нужно заняться именно аналитикой, а разработку дополнительных «фич» отодвинуть на второй план.

Работа с Power BI, DAX и Power Query

Константин Севастьянов — 7 лет в информационно-аналитическом подразделении ФСО РФ, полтора года в онлайн-кинотеатре TVzavr — создавал инфраструктуру и развивал аналитику практически с нуля. С июля 2018 развивает аналитику в «Ситимобил» (сервис заказа такси) в условиях быстрого роста компании, внедряет аналитическую базу данных и BI-инструменты.

— Константин, чему научатся студенты и что они смогут делать с помощью Power BI?

— Научатся визуализировать информацию и отвечать на вопросы бизнеса, смогут подготавливать, очищать и обрабатывать данные, выбирать различные визуализации в зависимости от типа входных данных.

Но, помимо технических моментов, мне важно донести до студентов, что главный инструмент аналитика — это здравый смысл, а Power BI лишь упрощает работу и помогает быстрее получать информацию в наглядном виде.

— Сделают ли слушатели практический проект за время учебы?

— Думаю, это будет проект на примере сервиса такси, где студенты смогут использовать сгенерированный набор данных.

Работа с Python, pandas и SQL

Илья Браславский — Data Scientist в «Ситимобил». Анализировал финансовые данные в BlackmoonFG и геологические данные в Сколтехе. Окончил магистратуру МФТИ по направлению «Интеллектуальный анализ данных».

— Илья, зачем продуктовому аналитику изучать Python? И, в частности, библиотеку для научных вычислений pandas?

— Python — один из самых простых с точки зрения синтаксиса языков программирования, и в последние несколько лет он стал де-факто индустриальным стандартом для задач анализа данных. Например, та же библиотека pandas позволяет в несколько строчек кода посчитать ряд статистик для данных: математическое ожидание, медиану, дисперсию.

— Сколько длится блок? Много ли практических заданий нужно будет сделать студентам в ходе или по итогам занятий?

— Блок будет состоять из 7 занятий. В начале мы разберем основы синтаксиса и основные библиотеки для анализа данных. После этого студентов ждет введение в теорию вероятности и математическую статистику. Финальное занятие посвятим обзору ряда инструментов разработчика.

Практические задачи обязательно будут сопровождать каждое занятие. Каким будет итоговый проект по Python для аналитиков — посмотрим, но вводные данные для него студенты, безусловно, получат.

Остались вопросы? Напишите консультанту в чат или оставьте комментарий к статье. Записаться на курс продуктовой аналитики в GeekBrains можно прямо сейчас.

 Эксперты рассказали, как с ним справляться, чтобы сохранить здоровье и продуктивность.

Перезагрузитесь с помощью дыхательных упражнений

Любовь Богданова, психолог, дыхательный терапевт, автор курса «Антистресс-экспресс для офиса» и «Свобода от стресса»:

— Самое простое и признанное специалистами средство для борьбы со стрессом — дыхание. Оно всегда при вас, его невозможно забыть, как таблетки, и ему не нужно электричество, как гаджетам с приложениями.

Обратите внимание — не все, что вы встретите о дыхании от стресса, действительно работает. Например, медленное и спокойное дыхание успокаивает, и может показаться, что это и есть избавление от стресса. Но успокоение — это только «заглаживание», все напряжения остаются.

Избавиться от стресса — значит вывести напряжение наружу. Вы же чувствуете, что подсказывает природа? Крикнуть, стукнуть, бросить, разбить что-то... Так что не идите против инстинктов, а используйте природный принцип, чтобы освободиться от напряжения. К тому же успокоительное дыхание занимает несколько минут, а антистрессовое — 10–20 секунд!

Любовь советует такие упражнения против стресса:

«Стрельба из лука»

Сделайте глубокий вдох — вы натянули тетиву лука. Со звуком «пх» выпустите стрелу, к которой прикреплены ваши переживания, мышечное напряжение в теле. «Пх» — улетели. Эмоциональное напряжение — несколько стрел: «пх», «пх», «пх», — неспешно, по очереди. Напряжение в мыслях «я плохой, люди плохие, мир плохой, жизнь плохая» — «пх», «пх», «пх». Следите за полетом каждой стрелы, не спешите.

«Дыхание змеи»

Сделайте глубокий вдох, а выдох выполните с усилием, чтобы звучал звук «сссссс». Повторите несколько раз.

«Энергетический душ»

Самое сильное дыхательное упражнение из серии «антистресс», которое можно выполнять на работе. Найдите уединенное место — пустую переговорку, запасную лестницу, даже офисный туалет подойдет. Нужно будет сделать 20–30 вдохов и выдохов подряд, соединяя дыхание с движением рук. Это «удалит» внутреннее напряжение.

Вдохи и выдохи делайте через нос. Глаза закройте. Исходное положение: стоя, руки в мягких кулаках возле плеч, будто вы держите штангу на груди. На вдохе руки выстреливают вверх, пальцы резко раскрываются. На выдохе — расслабленно падают в исходное положение к плечам. Выдох свободный, происходит сам собой. Снова активный вдох с выбрасыванием рук вверх — и расслабленный свободный выдох с падением рук. Повторите 20–30 раз.

Будьте готовы к мощному результату: гудению, жару, вибрации в руках и корпусе, опустошению в сознании и эмоциях! Это упражнение «обнуляет» психоэмоциональную нагрузку. Осторожно: повышает давление!

После антистрессового дыхания полезно сделать и успокаивающие упражнения, которые повысят стрессоустойчивость в долгосрочной перспективе. Это своего рода «дефрагментация диска».

«Квадрат дыхания»

Вдох на 4 счета, задержка на 4 счета, выдох на 4 счета, задержка на 4 счета. Повторите 10 раз.

«Когерентное дыхание»

Медленный вдох — плавно в течение 6 секунд, свободный выдох — 6 секунд, далее снова вдох — 6 секунд, выдох — 6 секунд и так далее. Дышите так 5 минут. В идеале упражнение надо делать три раза в день по 5 минут, или одним подходом в 15–20 минут.

Любую ситуацию поворачивайте в свою пользу

Даже в увольнении можно найти позитив. Это возможность начать все с чистого листа, найти работу поинтереснее, а еще лучше — обрести себя. Ну или просто отдохнуть.

Не ленитесь отдыхать

Владимир Якуба, бизнес-тренер:

— Отдыхайте в любой момент, когда это возможно. Если вы идете на встречу мимо картинной галереи, а до переговоров еще 40 минут, зайдите посмотреть на рисунки. Переключаться важно.

Спорт, спорт, спорт

Мустаева Светлана, кандидат медицинских наук, руководитель Центра спортивной медицины, ЛФК и физиотерапии:

— Как практикующий врач я регулярно работаю с пациентами, которые пренебрегали разумной физической активностью, то есть не занимались профилактикой. Мой совет всем, кто хочет избежать пагубных проявлений стресса: тренировки не менее трех раз в неделю.

Чем помогает спорт? Он способствует выработке эндорфинов — гормонов, мобилизующих кровоснабжение. Улучшение кровоснабжения, в свою очередь, повышает работоспособность, исключает застойные явления, повышает микроциркуляцию в сосудах. Особенно в головном мозге, которым так активно пользуются программисты. У IT-специалистов сидячая работа, и это может вызвать застойные явления в области малого таза. Результат — снижение либидо, простатит у мужчин, нарушение репродуктивного здоровья у женщин. Спорт и фитнес помогут избежать этих неприятностей, которые сами по себе вызывают стресс.

«Я молодец»

Наталья Жолудева, клинический психолог, окончила факультет психологии МГУ им. М. В. Ломоносова и Московский гештальт-институт:

— Каждый раз, сделав что-либо полезное (даже просто закрыв вкладку с фейсбуком и открыв редактор кода), говорите себе: «Я молодец!». Если никто не дает вам обратную связь, организуйте ее себе сами! В нашей культуре, увы, это не принято, но не стоит повторять эту порочную практику до бесконечности. И если у вас есть подчиненные — не скупитесь на благодарность и похвалу. Это позволит вам больше делегировать, а им — чувствовать себя успешными. Запомните: в любой момент вы можете остановиться — и всегда найти, за что похвалить себя. Поругать вас всегда успеют. Если вы вдруг не обнаружили повода для похвалы — сделайте что-то продуктивное и скажите себе: «Я молодец»!

Негативная обратная связь тоже ценна и может снизить уровень стресса. Просто важно давать оценку делам и действиям, а не людям. Сравните ситуацию, когда вам говорят: «Вы идиот, как вы могли сделать такую глупость!», — с репликой в духе: «Вы хороший работник, но ошибка нам дорого стоила, и я вынужден сделать замечание». Разницу почувствовали?

Тренируйте осознанность

Елена Кружилина, руководитель службы внутреннего контроля компании ICL Services:

— Ученые подтвердили положительное влияние практик осознанности на нервную систему. Сделайте их привычкой:

1. Осознанность приятных переживаний. Погрузитесь полностью в приятный момент: какие у вас мысли и эмоции, телесные ощущения? Можете записать это в дневник. Эта практика может быть чем-то совсем простым: нежиться утром в постели, смотреть на облака, слушать смех ребенка.

2. Осознанное дыхание. Чем бы вы ни занимались, осознайте тело: позу, опору под ногами и бедрами. Сделайте глубокий вдох и выдох и наблюдайте, как движется тело при дыхании. Чтобы успокоиться, выдох должен быть в 2−3 раза длиннее вдоха. Это можно делать абсолютно везде, не привлекая внимания.

3. Повседневная осознанность. Во время простых ежедневных действий наблюдайте за каждым движением тела и ощущением, ловите взглядом предметы, чувствуйте запахи и оттенки вкуса. Например, когда принимаете душ и чистите зубы, завариваете чай, моете посуду или гуляете.

Учитесь понимать мотивы людей

Татьяна Порицкая, психолог:

— Человек может вредить вам по двум причинам: либо он видит в этом пользу для себя, либо защищается. Ваша задача — определить мотив и устранить его.

Например, начальник ругает вас. Почему? Потому что он считает, что только так можно влиять на сотрудников и повышать свой авторитет. Нужно объяснить ему, что когда на вас орут, вы теряетесь и ничего не можете делать.

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

А как вы справляетесь со стрессом?

Один из важнейших инструментов для эффективной работы предприятия — это сервис планирования и управления проектами. В зависимости от размеров, отрасли и целей это могут быть относительно простые системы контроля версий, крупные бизнес-решения или внутренние разработки. Только по данным портала Capterra таких программ несколько сотен. Мы сфокусируемся на 13 сервисах, наиболее популярных в нашей стране.

Trello

Когда речь заходит о взаимодействии в небольшой группе разработчиков, Trello — первое, что приходит в голову. Легкий в освоении, бесплатный в ограниченной версии, интегрируемый с популярными сервисами — в общем, идеальный инструмент для тех, кто еще вчера не задумывался об организаторских задачах.

Главная фишка — простой интерфейс, состоящий из досок с заданиями и списков задач. Работает функция drag-and-drop, так что поменять статус задания можно одним движением мыши. А конечный пользователь может вообще не заходить в основное тело планировщика — для его задач выделяется отдельное окно.

GitHub

GitHub можно рассматривать как организационное ПО с большой натяжкой. Но это не мешает компаниям использовать его в качестве единственного инструмента для взаимодействия сотрудников. Плюсы GitHub очевидны: простой интерфейс, удобство использования для коллективной разработки кода, интеграция с множеством IDE, большой хаб открытых исходников. Но за пределами программирования GitHub не эффективен, потому что практически не предлагает бизнес-решений именно по управлению проектом.

Slack

Корпоративный мессенджер, в свое время ставший самым быстрорастущим приложением в сегменте. В бесплатной версии вы получаете хранилище на 5 ГБ и 10 тысяч сообщений, но куда круче другое — интеграция с множеством продуктов: от Google Docs и Twitter до сервисов управления проектами. Вкупе с приятным дизайном это делает Slack одним из самых популярных бизнес-решений для взаимодействия сотрудников. Но в отрыве от «конкурентов» он малоэффективен — просто очередной мессенджер.

Яндекс.Трекер

Сервис, запущенный в прошлом году, быстро нашел поклонников. В Яндексе постарались поместить в продукт максимум функций: планировщик задач и совещаний, оптимизацию работ по выбранной методологии, обработку заявок, расчет отпусков, создание типовых ТЗ, — в общем, практически все, что может потребоваться в организации со штатом более пяти человек.

Бесплатной версии нет, только пробная на 60 дней. Потом придется платить — от 93 рублей за человека.

Мегаплан

Если вы уже работаете в государственном секторе или в перспективе хотите в него попасть — ознакомьтесь с сервисом «Мегаплан». Довольно качественная CRM, которая позволяет брать под контроль выполнение задач, регулировать сроки, финансы, создавать отчеты. При этом у сервиса приятный дизайн и есть мобильные приложения в AppStore и Google Play, позволяющие оперативно знакомиться с выкладками сотрудников. Еще один большой плюс для большинства российских компаний — интеграция с 1C. Цена — от 279 рублей за одну лицензию.

Битрикс24

Сервис для управления бизнесом, который выбирают свыше 4 миллионов российских компаний. Несмотря на шероховатости в дизайне, «Битрикс» напичкан решениями: досками задач, мобильными приложениями, поддерживает интеграцию с call-центром, почтой, облачными сервисами, «1С:Предприятие». Есть групповой чат, можно в несколько кликов сделать отчет и даже создать сайт. Для маленьких групп — бесплатно.

JIRA

Система управлениями проектами, успешно работающая на рынке более 15 лет. Благодаря этому опыту и обширной функциональности, JIRA используется в многих крупных компаниях: PepsiCo, CERN, LG, Electronic Arts, Thales. Да, на фоне многих современных конкурентов JIRA проигрывает: в удобстве, интеграциях, уровне мобильного приложения. Но уже потому, что продукт не становится хуже, своего пользователя JIRA почти не теряет — ни у нас, ни на Западе.

Asana

Популярный таск-трекер, интегрирующийся с Evernote, Google Docs, JIRA, Slack, GitHub, но без русификации. Именно это отталкивает многих российских пользователей, хотя есть и другие неприятные мелочи: вопросы по быстродействию, перегруженность элементами, плохая интеграция с почтой.

Zoho Projects

Планировщик, завоевавший популярность благодаря простоте и качественной реализации Agile-методологии. Здесь все те же доски, возможность планировать совещания, оставлять логи спринтов, строить на основании трудозатрат диаграммы, генерировать отчеты. В целом, ничего особенного. Но то, как это сделано в вебе и мобильном приложении, заставляет присмотреться к Zoho Projects.

ПланФикс

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

YouTrack

Система управления проектами и анализатор ошибок от JetBrains. Нацелена на сферу программирования со всеми сопутствующими возможностями: простым интерфейсом, гибким поиском, шорткатами, настройками под Scrum- и Kanban-задачи и полной интеграцией со всеми продуктами JetBrains. Команды до 10 человек могут пользоваться сервисом бесплатно.

Redmine

Одна из самых популярных open source систем для управления проектами. Хорошую функциональность можно подтянуть при помощи плагинов — генерацию отчетов, интеграцию с другими продуктами. Без них Redmine — это простой планировщик с календарем и возможностью прикреплять заметки. Прекрасно подойдет для компании, где больше 10 человек, а если среди них есть толковые программисты для создания плагинов — это хорошо вдвойне.

Простой бизнес

Отечественная CRM, позволяющая установить полный контроль не только над проектами, но и за сотрудниками. Система может отслеживать рабочую почту, записывать звонки, позволяет создавать удобную клиентскую базу, всевозможные отчеты. Ее большой плюс, который не дают веб-сервисы, — возможность работать офлайн. То есть вы можете создавать задачи, прикрепять файлы, а до исполнителя они дойдут, как только вновь нащупаете доступ в интернет.

Это далеко не полный перечень ПО для планирования и управления ресурсами вашей команды. Абсолютно точно можно сказать, что идеальной системы не существует, а возможностей большинства решений вполне хватит для стартового периода внедрения. А позже, на основании впечатлений, вы сможете перейти на более удобную программу. Какие рассмотреть в первую очередь, вы теперь знаете.

Kanban вряд ли можно назвать полноценной методологией — это просто удобный инструмент, который можно использовать практически с любым подходом к разработке. Kanban делает нагляднее работу над проектом, позволяет отслеживать выполнение отдельных задач и создание функциональных возможностей программного продукта. Кроме того, с этой системой легче контролировать нагрузку специалистов.

Откуда пошел Kanban

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

Это было удобно руководству: не надо отвлекать сотрудников или мастеров. Чтобы узнать, чем они заняты, достаточно прочесть записки. Вскоре эта система закрепилась как официальная практика.

Впоследствии Kanban совершенствовался, пока не пришел к современному виду. Но сохранил в основе простейший принцип доски с записками, на которых фиксируются производственные задачи.

Kanban был с самого начала тесно связан с гибкими методологиями производства, которые впервые внедрили в компании «Тойота». С Agile-методологиями в IT-сферу пришел и адаптированный Kanban. Но сегодня его успешно «скрещивают» с другими методологиями.

Пристальный взгляд на систему

В основе Kanban’а лежит простая мысль: объем незавершенной работы надо ограничивать. Любую новую задачу можно начинать не ранее, чем выполнена одна из начатых. Это не значит, что в работе должна быть только одна задача, — их может быть несколько. Принципиально, чтобы это количество было ограничено.

Чтобы контролировать выполнение задач было проще, процесс визуализируют на доске, разделенной на несколько колонок. В самом простом варианте это «В ожидании», «В работе» и «Выполнено», но можно добавлять дополнительные, если хотите детально отслеживать путь каждой задачи от постановки до реализации. На первых этапах лучше ограничиться необходимым минимумом.

Все задачи, которые поступают от заказчика, записываются на стикеры и размещаются в графе «В ожидании». Им можно назначить приоритет: более важные размещают выше и принимают в работу в первую очередь, а второстепенные — только когда будут выполнены приоритетные. Как только разработчик приступает к работе над очередной задачей, соответствующий листок переносится в графу «В работе». Когда она выполнена, стикер отправляется в последнюю графу.

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

Искусственное ограничение выглядит контрэффективным, но на практике оно вырабатывает совершенно иной подход и отношение к незавершенным делам. Любая задержка, промедление в выполнении работы благодаря Kanban-доске будут сразу заметны — не только самому разработчику, но и всем коллегам.

Это стимулирует не бросать начатое, столкнувшись со сложностями. Если объем незавершенной работы не ограничен, позволяешь себе переключиться на более простые задачи, оставив сложную «на потом» — а это риск оставить ее навсегда в статусе отложенной.

Проблема разработчика — это проблема команды. Kanban стимулирует программистов активнее сотрудничать, обсуждать производственные вопросы и искать способы их решить.

Kanban не только делает прозрачнее создание ценности продукта, но и показывает узкие места, очереди, отклонения и потери — все, что отрицательно влияет на продуктивность команды.

Доска и бумажки — вот и весь Kanban?

Конечно нет. Любая методология нацелена на оптимизацию процессов производства. Kanban как инструмент можно совместить почти с любой методологией, чтобы ускорить разработку программного обеспечения и сделать ее эффективнее.

Поскольку количество задач в колонках Kanban-доски ограничено, время выполнения каждой меньше зависит от внеплановых работ и завалов. Для всех задач можно измерить среднее время выполнения и сделать разработку более предсказуемой и удобной в планировании. Кроме того, это позволяет выявить проблемы и сложности, замедляющие работу, и избавиться от них.

Важнейшее преимущество Kanban’а — наглядность. Видно не только то, какие задачи выполнены, находятся в разработке или ждут своего часа, но и насколько загружены разработчики. На доске можно выделить для каждого программиста или рабочей группы свою строку. Тогда Kanban-карточки размещают в соответствующей колонке и строке, назначая задачу конкретным сотрудникам.

Еще один прием — разбивать доску на технологические этапы. Разработка программы часто проходит через несколько стадий:

• постановка задачи (разработка технического задания),
• создание кода,
• тестирование,
• сборка рабочей программы,
• передача пользователю.

В крупных компаниях над этими этапами работают отдельные команды специалистов: технические писатели формулируют требования, спецификации и техзадания, разработчики заняты только производством кода, тестировщики — его проверкой на работоспособность и соответствие требованиям.

Создайте на Kanban-доске колонки, соответствующие каждому этапу, и будет легче определить, как движутся задачи в рабочих группах, насколько специалисты загружены и не «провисает» ли работа над проектом.

Сколько вешать в граммах?

Каким количеством Kanban предлагает ограничивать задачи «в работе», чтобы коллектив справлялся с ними в оптимальные сроки? Универсального ответа нет. Единственный совет — экспериментируйте!

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

Если колонке N скопились задачи, а N+1 почти все время пустует, — это признак перегруженности. Ограничение надо ужесточать.

Kanban предлагает разработчикам свободу в выборе решений. Если оказывается, что при установленном ограничении вы не укладываетесь в график — уменьшите значение. Осталось свободное время, команда работает в расслабленном режиме — поднимите планку. Не бойтесь «крутить настройки»: сломать Kanban невозможно! Несколько попыток — и вы найдете комфортный для всех ритм.

Тренируемся на кошках

Предположим, у нас есть задачи и самая простая Kanban-доска из трех колонок: «В ожидании», «В работе», «Завершено». Работать над проектом будет команда из пяти человек. Выставим единицу как ограничение для колонки «В работе»: одновременно в ней может находиться не более одной задачи.

При таком подходе обнаружим, что пока одна часть коллектива создает код, другая изнывает от безделья. Это не так уж страшно, если такие ситуации возникают редко. Но мало смысла впятером трудиться над одной задачей. Время выполнения будет минимальным, но остальные задачи будут слишком долго «в ожидании» и общий темп работы над проектом замедлится.

Если поднять ограничение до десяти, на каждого разработчика придется в среднем по две задачи. Это допустимый максимум. Ограничение не обязывает держать в работе именно столько задач — их может быть меньше.

Теперь программисты загружены «по полной программе» и никто не раскладывает пасьянс в ожидании хоть какого-то дела. Но рискуем столкнуться с ситуацией, когда разработчик оставит «зависшую» задачу, с которой не сумел справиться, и возьмется за другую, выполнит ее и примется за третью. Все это время первая незаконченная задача остается номинально «в работе», но по факту заброшена.

Слишком низкий лимит незавершенных задач — очевидное зло, но и высокий чреват проблемами. Надо подобрать такое ограничение, которое будет создавать равномерную и постоянную нагрузку, не допуская «зависания» незаконченных задач.

А что насчет ограничений в других колонках?

Колонка «Готово» свободна от лимитов — чем больше работы сделано, тем лучше!

Есть ли смысл накладывать ограничения на колонку «В ожидании», где скапливаются задачи, к которым разработчик еще не приступал, и нужна ли она вообще? Ведь Agile-методологии подразумевают постоянное общение с заказчиком — новые задачи можно получать, когда завершена предыдущая.

И все-таки иметь небольшой «буфер» задач полезно. У них может быть разный приоритет и сложность. Сегодня заказчику хочется изменить дизайн элементов управления во всей программе: эта задача явно отнимет приличное время, хотя не является критически важной для работы пользователя. А завтра он вспомнит, что срочно нужен отчет по продажам — небольшой и не очень сложный. Но разработчик уже взялся за дизайн, и на Kanban-доске нет места для новой задачи.

Если бы обе задачи висели на доске в графе «В ожидании», разработчик взялся бы сначала за более важную, а незначительные, но объемные правки отложил на свободное время.

Колонку «В ожидании» тоже можно ограничить удобным для разработчика и заказчика количеством задач. Заказчик может заменять задачи: чтобы разместить срочную в заполненной колонке, надо убрать менее важную.

Вилка или ложка — что лучше?

Обобщим основные правила использования Kanban’а.

1. Сделайте работу наглядной.

• Разделите на задачи.
• Каждую запишите на стикер.
• Распределите стикеры по графам на доске.

2. Ограничьте объем незавершенной работы.

• Вычислите, какое количество незавершенных задач будет оптимальным на каждом этапе.

3. Измеряйте время

• Вычислите оперативное время, которое в среднем требуется для выполнения каждой задачи.
• Оптимизируйте работу, чтобы свести оперативное время к минимуму.
• Прогнозируйте работу над задачами.

Чтобы Kanban работал и приносил результаты, недостаточно повесить доску на стену. Если вместо анализа рабочих процессов, экспериментов и поисков оптимального ритма работы руководитель заставляет сотрудников банально перевешивать листки из одной колонки в другую, — это не Kanban, а просто доска с бумажками.

Когда Kanban пытаются сравнивать с другими методологиями и делать выводы о том, какой подход продуктивнее и выгоднее, это похоже на споры о том, что лучше — вилка или ложка. В отрыве от конкретных ситуаций и специфики IT-компании подобные рассуждения бессмысленны. Не надо сравнивать инструменты — стоит попробовать те, которые кажутся подходящими и с которыми готова работать команда.

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

Виртуальные Kanban-доски

Вы уже определились, в каком углу будет лучше смотреться Kanban-доска? Не торопитесь вбивать в стену гвозди. Ведь давно уже существуют программные решения, которые предлагают пользователям аналоги Kanban-досок. В отличие от стикеров на стене, такая Kanban-доска будет доступна не только в офисе, но и в любой точке мира — идеальное решение, если в команде есть удаленщики.

Trello

Поддерживает любое количество проектов, каждый со своей доской и произвольным составом задач и разработчиков. Можно ставить метки и комментировать задачи, прикреплять файлы объемом до 250 Мб. Есть функция «чек-лист»: можно создать множество подзадач, помечать выполненные и видеть прогресс в процентах.

Благодаря качественному API Trello интегрируется с другими решениями — например, Slack. Есть клиентские программы для основных платформ — Windows, iOS, Android, доступен веб-интерфейс.

Практически весь функционал представлен в бесплатной версии. Приятный плюс — поддержка русского языка. Платная версия добавляет «вкусностей» вроде пользовательских стикеров, фонов и неограниченных по объему вложений.

Kanbanchi

Достойный конкурент Trello. Богатая функциональность даже на бесплатном тарифе: неограниченное количество колонок и задач, комментарии и теги. Задачи можно маркировать цветами по типам, чтобы легче ориентироваться на доске. Есть чек-лист, для каждого элемента которого можно задать «вес» — продолжительность выполнения относительно всей задачи в целом. Этот параметр учитывается при вычислении объема выполненной работы.

Поддерживаются альтернативные представления списка задач: обычный текстовый список и диаграмма Ганта на платных тарифах.

Интерфейс у Kanbanchi англоязычный. Но если вы усвоили принципы Kanban’а, разобраться в деталях не составит труда.

Битрикс24

Битрикс24 — это полноценная CRM со встроенной Kanban-доской. Позволяет вести внутри организации множество проектов и прикреплять к ним специалистов. Создавая задачу, сотрудник автоматически помещает карточку на персональную Kanban-доску исполнителя. Это один из вариантов представления задач — их также можно вывести в виде обычного списка или диаграммы Ганта.

Для любой задачи можно устанавливать сроки исполнения, добавлять подзадачи, комментировать, прикреплять файлы.

Система платная. Бесплатный тариф есть, но в нем нет ряда полезных функций, и работать на нем могут не более 12 сотрудников, а объем облачного хранилища ограничен 5 Гб. Но для небольших стартапов или маленьких коллективов разработчиков этого вполне может хватить. Зато помимо Kanbanа вы получите полноценную CRM-систему.

Kanbanery

Kanbanery позволяет создавать на доске произвольное количество колонок с любыми названиями. Для каждой задачи можно указать сроки исполнения, прикрепить файлы, добавить комментарии, отслеживать изменения в карточках. Чтобы получить общую картину работы над проектом, можно воспользоваться продвинутыми графическими отчетами. Разработчикам ПО будет особенно полезна интеграция с GitHub. Есть мобильные приложения Kanbanery для iOS и Android, а также API для интеграции сервиса с пользовательскими приложениями.

Это платный сервис: он предлагает несколько тарифов, различающихся количеством активных пользователей — от 5 до 50. Бесплатный тариф тоже присутствует, но работать с одной доской смогут не более двух человек.

Taskify

До крайности простой онлайн-сервис, позволяющий создать Kanban-доску из трех колонок: To do («Сделать»), In progress («В работе») и Done («Сделано»). На доске размещается любое количество задач, которые изначально создаются в To do. Для каждой указывается дедлайн и исполнитель. Карточки с задачами при приближении дедлайна меняют цвет от нейтрального серого до красного.

Kanban-доска Taskify доступна в режиме онлайн для любого количества пользователей — достаточно поделиться ссылкой на нее, в том числе через социальные сети.

Плюсы: Taskify доступен бесплатно и без регистрации, его просто осваивать и легко использовать. Минус — набор функций скудный, на грани аскетизма.

На этом список онлайн-сервисов не заканчивается. Среди многообразия решений непременно найдется то, которое подойдет вашей команде и поможет в работе!