На связи технический директор 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 наиболее приоритетна, — ее и нужно брать в работу первой.

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

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

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

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

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

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

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

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

Избавиться от стресса — значит вывести напряжение наружу. Вы же чувствуете, что подсказывает природа? Крикнуть, стукнуть, бросить, разбить что-то... Так что не идите против инстинктов, а используйте природный принцип, чтобы освободиться от напряжения. К тому же успокоительное дыхание занимает несколько минут, а антистрессовое — 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 доступен бесплатно и без регистрации, его просто осваивать и легко использовать. Минус — набор функций скудный, на грани аскетизма.

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

GeekBrains уже рассказывал о «Водопаде» (Waterfall), на очереди — Agile: познакомимся с этой схемой, по которой организуют работу многие коллективы программистов.

В феврале 2001 года семнадцать человек — крупные IT-специалисты и разработчики — собрались на горном курорте в штате Юта. Отдохнули, пообщались и составили небольшой документ — Agile-манифест.

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

Гибкость во всем

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

Не углубляясь в детали, вспомним, как устроена разработка по методологии Waterfall:

1. Выдвигаются требования к ПО, разрабатывается техническое задание (ТЗ).
2. Поставленные задачи воплощаются в коде.
3. Выполняется тестирование.
4. Готовое ПО внедряется в работу.

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

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

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

Чтобы понять, как это работает, представим коллектив разработчиков, создающих аудиоплеер. Уже написан костяк программного кода: интерфейс и базовый функционал. Программа умеет воспроизводить файлы формата MP3, WAV и OGG. Но пользователи предлагают добавить проигрывание CD-дисков и подключить горячие клавиши, чтобы быстро управлять плеером.

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

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

На этом итерация завершается — и начинается новый виток разработки.

Идеи и принципы

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

Четыре центральных идеи Agile Manifesto

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

12 принципов Agile

1. Задача высшего приоритета — регулярно и как можно раньше удовлетворять потребности заказчика, предоставляя ему программное обеспечение.
2. Учитывать, что требования могут измениться на любом этапе разработки. Если изменения быстро вносятся в проект, заказчик может получить конкурентные преимущества.
3. Выпускать версии готовой программы как можно чаще — с промежутком от двух недель до двух месяцев.
4. Ежедневно вместе работать над проектом — разработчикам и заказчикам.
5. Поручить работу мотивированным профессионалам. Обеспечить поддержку и условия, довериться им — и работа будет сделана.
6. Общаться напрямую — это самый эффективный способ взаимодействия внутри команды и вне ее.
7. Считать главным показателем прогресса работающий продукт.
8. Поддерживать постоянный ритм работы — касается и разработчиков, и заказчиков.
9. Уделять пристальное внимание техническому совершенству и качеству проектирования — это повышает гибкость проекта.
10. Минимизировать лишнюю работу.
11. Стремиться к самоорганизующейся команде — в ней рождаются наиболее эффективные и качественные решения.
12. Всем участникам команды — постоянно искать способы повышать эффективность работы.

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

Scrum

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

Впервые термин прозвучал в 1986 году. Японские исследователи Икуджиро Нонака и Хиротака Такеучи в статье The new New product development game сформулировали принципы, позволяющие быстрее создавать новый продукт. Среди условий такой разработки назвали самоорганизующуюся команду специалистов, их полную свободу в творчестве и работе — без ограничений со стороны топ-менеджмента. Этот подход авторы описали так:

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

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

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

Методика, предложенная Нонака и Такеучи, нашла применение в IT-сфере, разработке инженерных решений в машиностроении, электронике. В 90-х Scrum оформился как проработанная и цельная методология, оброс конкретными приемами, помогающими с нуля наладить работу команды. Благодаря Кену Шваберу и Джеффу Сазерленду Scrum пришел в IT и приобрел популярность среди разработчиков — некоторые даже считают эту методологию революционной.

Командный дух

В команде, работающей по принципам Scrum, нет внутренней иерархии: ни руководителей, ни подчиненных, ни указаний-приказов. Есть два особых члена группы: product owner — владелец продукта, и scrum master — скрам-мастер.

Product owner лучше всех знает, каким должен быть продукт. Зачастую это заказчик, его представитель или сотрудник, ответственный за взаимодействие с клиентом. Он должен ясно понимать, что именно требуется конечному пользователю программы. Все пожелания и предложения по функциональности и внешнему виду продукта (в Scrum они называются stories — истории) он заносит в специальный список — Product Backlog. Бэклог формируется до старта разработки и по ходу постоянно пополняется. Здесь же указывают приоритеты доработок.

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

Рывок! Еще рывок!

Работа над программой в Scrum, как и в Agile в целом, разделена на итерации. Здесь любят спортивную терминологию: эти отрезки разработки называют забегами или спринтами. Каждый начинается с того, что команда сообща определяет, какие именно истории из списка владельца продукта она сможет реализовать на этом спринте. Выбранные идеи переносятся в отдельный список — sprint backlog. Фиксируется цель: что конкретно команда сможет продемонстрировать пользователю в итоге. Задачи распределяют, и начинается забег.

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

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

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

XP — программируем экстремально!

Речь не о Windows XP. Под этой аббревиатурой скрывается еще одна методология из класса Agile: eXtreme Programming — экстремальное программирование. Ее придумал разработчик Кент Бек, развивали Уорд Каннингем, Мартин Фаулер и другие. Это набор простых принципов и практик, которые помогают наладить эффективную работу.

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

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

В экстремальном программировании все эти принципы доведены до предела. Нет времени объяснять — нужно делать! Планируют на короткий срок. Итерации разработки максимально сжатые. Чем быстрее выйдет рабочая версия — тем лучше. Реализуется самое простое из решений, а код пишется и тестируется параллельно.

Экстремальные практики

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

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

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

Есть риск: примитивное техническое решение, которое успешно работало на первых порах, может стать проблемой, когда программа начнет развиваться и потребуется более продвинутая функциональность. Это может показаться минусом технологии: XP не любит планировать на отдаленную перспективу, предпочитая оперативно перестраиваться на ходу. Но на практике редко возникают ситуации, когда работающий код надо переписать с нуля. Их смогут предвидеть опытные профессионалы, которые работают в agile-командах.

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

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

Парное программирование — одна из полезных практик XP

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

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

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

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

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

Переработку XP не поощряет: требует от программистов неукоснительно соблюдать рамки 40-часовой рабочей недели. Никаких «я только допишу эту функцию»! Если не умеете переключаться и отдыхать — скоро не сможете и продуктивно работать.

Экстремально — не значит плохо

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

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

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

Никакого волшебства

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

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

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

Преимущества Agile

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

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

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

Темная сторона силы: недостатки Agile

Не факт, что программа когда-нибудь будет завершена.

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

Но если вы планируете долговременное сотрудничество с заказчиком и он готов платить за все время разработки — почему нет?

Пользователь требует все и сразу.

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

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

«Золотые пользователи»

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

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

Строительство без чертежей

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

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

Постоянная спешка

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

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

До тех пор, пока работает…

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

Кому подойдет Agile

Методологии класса Agile хорошо себя покажут, если:

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

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

Больше методологий богу методологий!

Мы рассмотрели Scrum и XP, но класс Agile включает и другие методологии. Есть любопытные подходы и вне Waterfall и Agile. Продолжим в следующей статье.

Кадр из фильма «Области тьмы», 2011, Relativity Media

Хотите больше запоминать, быстрее мыслить, проще концентрироваться, лучше решать задачи, стать эрудированнее, внимательнее и счастливее? И чтоб бесплатно, без таблеток и скуки? Помогут эти приложения.

Mensa Brain Training

Приложение выпущено Mensa — старейшей и крупнейшей организацией для людей с высоким IQ, члены которой по результатам теста на коэффициент интеллекта превзошли 98 % населения Земли. Улучшает способность человека рассуждать, выявлять закономерности и учиться. Тренируются пять областей: объем памяти, концентрация, подвижность ума, восприятие, рассуждение. Можно проверить свой уровень по каждому показателю и посмотреть персональный рейтинг среди участников — Mensa Brain Index (MBI). Приложение пока доступно только на IOS.

Peak

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

Elevate

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

Trivia Crack 2

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

Lumosity

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

Memorado Brain Training

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

Clockwork Brain Training

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

Brainwell Mind Brain Training

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

Curiosity

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

Король математики

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

Happify: for Stress & Worry

Приложение поможет снизить стресс, избавиться от негативных мыслей и повысить психологическую устойчивость. Методики разработаны ведущими учеными и экспертами в области позитивной психологии и когнитивно-поведенческой терапии. 86 % людей, регулярно пользующихся Happify, через два месяца признались, что чувствуют себя счастливее. А ведь счастье — не рядовая характеристика жизни человека, а главный показатель благополучия, который влияет на все остальное.

А вы пробовали эти приложения? Знаете ли еще бесплатные тренажеры для ума?