keepsimple logo
keepsimple logo

#3. Рабочая среда менеджера

Итак, мы успели поговорить о том, что такое проект и какие основные артефакты используются в IT-проектах разработки ПО. В этой статье мы поговорим о рабочей среде современного менеджера.
Когда-то очень давно менеджмент практиковался в военном деле и в основном касался поручений которые офицеры из памяти конвертировали в приказы солдатам.
К началу 20го века некоторые люди поняли, что полагаться на память и смекалку сотрудников – чрезвычайно наивно и опрометчиво (спасибо Фредерик Тейлор!). Тогда они стали записывать свои задачи на листах бумаги, прибивая гвоздями к стенам, для наглядности.
Во второй половине 20го века японцы одними из первых поняли бездонный, колоссальный потенциал менеджмента в целом, и оптимизации процессов в частности. Тогда они решили в добровольно-принудительном порядке ввести жесткие системы управления на всех своих предприятиях.
Одна из таких систем, упоминание о которой, кажется, обязательно для всех кто пишет книги о менеджменте – Канбан. Суть Канбан метода сводилась к тому, чтобы позволять сотрудникам предприятия (в частности - руководству) видеть текущий статус задач предприятия "в реальном времени". Для этого в самом центре (или у самой дальней стены) завода помещалась огромная доска, на которой специальный "менеджер" двигал огромные карточки с текстом-названием задачи.  
Компания Toyota работала над этим три года (это около тысячи дней, ага), и к 1962-му году, видимо, окончательно убедившись в его безусловной эффективности начала перевод всех своих производственных линий на Канбан.
По мере развития информационных технологий, менеджерами в IT-компаниях разрабатывались все новые и новые методы для управления и кординации деятельности IT-команд. В ход шли разные схемы печатающиеся на листах бумаги формата А-3 – А-4. С 80х все стали активно использовать ставшие мейнстримом стикеры-задачи (post-it notes), а в начале 2000х начались активные эксперементы с самыми разными фремворками.
То, что несколько десятков лет назад внушало сомнение и недоверие, теперь стало не просто нормой, а необходимостью. Современная же рабочая среда всецело состоит из веб и мобильных приложений. Все эти приложения, в сухом остатке сводятся к тому, чтобы решить три ключевых управленческих вопроса:  
Координация деятельности участников проекта и непрерывное слежение за текущим статусом;  
Коммуникация между участниками проекта;  
Обмен файлами между участниками проекта.
Теперь посмотрим пример такого ПО.
Прежде, чем мы перейдем к описанию разных приложений и подходов к управлению, я скажу то, что говорю всегда: любая программа, любой подход о котором мы говорим – это лишь инструмент. Не бывает плохих и хороших инструментов. Любой инструмент может быть полезен только если он соответствует решаемой задаче. Использовать нужно именно то, что подходит конкретной команде, конкретному проекту и его конкретным задачам. Все предельно просто.
Далее пойдет описание нескольких популярных инструментов и того, как я их использовал в разных проектах. Запоминать их смысла нет – информация дается скорее для того, чтобы понять о каких вообще инструментах идет речь когда говорится о рабочей среде проекта.
Инструменты координации
Итак, начнем с простого, но популярного инструмента – Asana.  
Скриншот с проекта разработки крупного портала киберспорта (eSports):  
Скриншот онлайн инструмента Asana

Инструмент дает возможность создавать списки, разделять их по заголовкам (1), добавлять задачи (одна строка = одна задача), отмечать решенные (5), назначать ответственных за задачу (6) и многое другое.
То, что система не дает по умолчанию, но что мы придумали для удобства это префиксы.  
Префикс, это условное обозначение созданное для нашего проекта с целью оптимизации времени затрачиваемого на понимание принадлежности задач в списке.
Так, префикс [IMPV] (2) мы приписывали к задачам, которые являлись совершенствованием уже существующего функционала. Префикс [Portal] (3) подчеркивал что речь идет о веб-платформе а не мобильном приложении (которое тоже было в разработке). Префикс [Player] указывал нам к какой странице вебсайта относилась задача (в нашем случае речь шла о Player Profile Page). Баги же мы помечали простым префиксом [BUG] (7). Все понятно, все просто.
Тот же проект, имплементирован в Trello:  
Скриншот проекта в онлайн инструменте Trello
Trello оперирует несколько иными понятиями: Лист (List) – обозначение колонки. Карточка (Card), Labels (Цветные маркеры на карточках), Powerups (Расширения, в основном, сторонних разработчиков, позволяющие добавить новый функционал к доске).
Функционал в разрезе:
  1. Backlog лист, куда помещались все задачи необходимые для имплементации;
  2. In Progress лист, куда перемещались задачи, которыми разработчики занимались в реальном времени;
  3. In Testing лист, куда перемещались задачи для тестирования командой тестировщиков;
  4. Done лист, куда перемещались уже решенные задачи;
  5. Префиксы, которые мы использовали. В частности, префикс [NEW] означал, что эта задача связана с новой фичей проекта, [Blocker] означал, что эту фичу необходимо имплементировать до запуска проекта в онлайн, [CMS] (7) – что задача связана с системой управления содержимым (Content Management System), а префикс [News] – что задача связана с дистрибуцией новостей на портале;
  6. Системная иконка Trello, показывающая, что в карточке есть описание (доступное по клику);
  7. Системная иконка Trello, показывающая, что к карточке прикреплены файлы;
  8. Посредством PowerUp-а “Custom Fields” мы добавили внешние индикаторы для разделения Frontend и Backend задач которыми занимались разные разработчики. Да, мы могли использовать префикс и для этого, но в какой-то момент мы посчитали что так будет удобнее и сошлись на этом;
  9. Системная иконка Trello, показывающая, что в карточке есть комментарии участников проекта;
  10. Системная иконка Trello, показывающая, что в карточке есть чеклист;
  11. Оранжевый лейбл, которым помечались задачи связанные с визуальным оформлением.
Еще один пример проекта собранного в Trello:  
Новый проект только-что добавленный в Trello доску
  1. В первой карточке прикреплен документ с описанием работ необходимых для выполнения. Бизнес-название документа “Scope of Work”, или короче – SoW. Это одно из названий документа, которым закрепляется перечень работ на который согласились обе стороны – заказчик, и исполнитель;
  2. Здесь выписаны используемые цвета, их значения и аббревиатуры которые будут использоваться в рамках этого проекта. Например, для того, чтобы в UserStories не писать многострочные названия ролей конечных пользователей, типа As Project Database Admin I want to… и далее, можно использовать APDBA I want to… и т.п.
  3. В этой карточке прикреплены все материалы связанные с дизайном, чтобы команда работающая над проектом не терялась в почтах и ссылках в поисках разных файлов типа шрифтов, картинок, логотипов, инструкций и т.д;
  4. Здесь дополнительные инструкции связанные с ведением проекта для общего ознакомления всех участников;
  5. Лист с Эпиками;
  6. Пользовательские Истории составленные на основе Эпиков;
  7. Задачи, составленные на основании Историй (В нашем случае, команда еще не успела составить перечень задач).
А это пример доски JIRA созданной в компании Joomag и используемой для работы с запросами нового функционала поступающим от клиентов:  
Скриншот. Пример проекта настроенного в онлайн инструменте JIRA
Функционал JIRA в разрезе:
  1. Названия колонок. В «NEW» добавляется новый запрос, во второй колонкепроводится проверка актуальности запроса и возможности его реализации. В третьей колонке оцениваются сроки выполнения, и так далее;
  2. Кол-во объектов в колонке;
  3. Участники проекта имеющие доступ к этой доске;
  4. Задача;
  5. Приоритет задачи;
  6. Кол-во дней сколько задача находится в колонке;
  7. Установленный срок выполнения задачи;
  8. Лицо, ответственное за выполнение;
  9. Название задачи;
  10. Порядковый номер задачи в формате аббревиатура:номер (ABC-25).
Эти, и множество других приложений созданы с единственной целью: координации деятельности участников проекта. Эти инструменты дают возможность настроить транспарентную систему, где каждый участник будет видеть чем занят его коллега и что и в какие сроки он должен выполнить сам.
Практически в каждом из подобных приложений предусмотрена возможность общения между участниками посредством комментариев, однако, как правило, подобные комментарии служат скорее примечаниями и заметками к задачам. Задачи же коммуникации решаются другими инструментами.
Инструменты коммуникации  
Наиболее популярными инструментами корпоративной коммуникации являются Microsoft Teams, Skype for Business, Discord и Slack. Пример интерфейса последнего:  
Скриншот коммуникационного инструмента Slack

Функционал инструмента в разрезе:
  1. Показывает доступные рабочие пространства (Workspaces), так, можно одновременно находиться в множестве workspace-ов с разными командами, проектами и задачами;
  2. Название текущего рабочего пространства;
  3. Каналы связи, обычно создаваемые для тематических обсуждений. Так, у нас есть канал который называется #yerevan-random для неформального общения (типа скидывания музыкальных треков и т.п.), и еще один канал #yerevan-announcements в котором публикуются важные оповещения;
  4. Каналы обозначенные решеткой (#) – публичные; каналы с замком - приватные;
  5. Список всех участников рабочего пространства, где каждый может написать кому угодно напрямую.
  6. Поиск сообщений. Работает как в частных беседах так и в групповых чатах.
Эти, и другие приложения имеют бесплатные версии и доступны любым желающим как в виде веб, так и мобильных приложений. В некоторых компаниях я видел как используют груп чаты в Facebook, WhatsApp, Telegram но это исключения.
Обмен файлами  
Итак, когда мы определились с тем, где мы будем собирать наши документы и распределять задачи, а также с тем, какие средства связи использовать. Остается последний вопрос – обмен файлами.
Любой проект подразумевает кооперацию с разными людьми, у которых свои собственные задачи и собственные методы работы. Кратчайший путь решения вопроса обмена файлов - создание папок в Dropbox или Google Drive.
Правда, прежде чем начать создавать папки было бы неплохо примерно представить деятельность каждого участника, и то, какими файлами придется оперировать. К примеру, если в команде несколько дизайнеров, и нам важно, чтобы дизайн материалы были собраны вместе – создаем папку дизайн и радуемся жизни.
Подведем итоги.
Да, мы ознакомились с тем, как можно легко и просто набросать рабочую среду для проекта и решить задачи координации, коммуникации участников и обмена файлов.
Однако все это мелочи по сравнению с самой большой сложностью во время создания новой рабочей среды для проекта / компании. Сложность о которой я говорю - это достижение договоренности о правилах кооперации между всеми участниками проекта.
Эти правила должны быть согласованы, и записаны так, чтобы они всегда были на виду, однако здесь многое зависит от культуры в которой вы работаете. Так, в некоторых, преимущественно латиноамериканских странах подобное документирование правил может обидеть чьи-то чувства, а в некоторых азиатских странах даже посчитаться грубым оскорблением.
Если же мы смогли достичь договоренности со всеми о том, в каких каналах чата и по каким вопросам мы общаемся, как распределяем файлы и как работаем с задачами, вторым для нас вызовом будет заставить всех участников выполнять эти договоренности.
По сути это парадокс.  
С одной стороны, вроде бы все очень заинтересованы в успехе проекта, иначе он бы и не начинался, однако с другой стороны, договоренности трактуются людьми как «нападки на их эго» и «посягательство на их свободу».  
Так, разработчик может «забыть» переносить завершенные задачи в колонку "Завершеныне задачи" на доске аппелируя тем, что у него «нет времени на перетаскивания карточек на доске» и что «писать код важнее». Дизайнер может сказать что «мне просто так не удобно работать, моя работа подразумевает вдохновение а не галочки в JIRA прожимать» и так далее.
Люди, частично выполняющие правила рабочего процесса всегда находят причины почему «не успели». Нам же, как менеджерам, следует удостовериться, что наш коллега понимает зачем была создана эта рабочая среда и зачем были обговорены рабочие правила.
Следующие пункты критически важно донести до всех участников проекта:
  • Очевидно, что менеджмент необходим;
  • Очевидно, что менеджмент, как и любой процесс, имеет градации качества «хорошо» - «плохо» в контексте выполнямой задачи;
  • Очевидно, что невыполнение договоренностей снижает качество согласованного процесса;
  • Очевидно, что снижение качества наносит урон команде;
  • Очевидно, что любое «забыл» или «нет времени» это одна из форм этого самого урона.
Я не буду вдаваться в то, как эти совершенно очевидные истины нужно донести до команды, и кто этим должен заниматься, однако это обязательная работа. Вдобавок к списку выше, менеджеры должны предельно четко понимать, что:
  • В рабочем процессе не должно быть исключений для кого бы то ни было.
  • В рабочем процессе должна быть синхронность в понимании целей проекта и методов их достижения.
  • В рабочем процессе эго сотрудника должно оставаться за рамками офиса, т.к. вреда от него всегда больше, чем пользы.
Как хороший пример организованности и следования договоренностями а всегда вспоминаю японцев. Об их преданности и щепитильности к договоренностям ходят легенды.
Будучи на 11м месте по кол-ву населения (124 миллиона), их экономика находится между 3м и 4м местом, после Китая (1,3 миллиарда человек), США (350+ миллионов), и Индии (1,3 миллиарда).
Япония – родина отцов основателей десятков и сотен легендарных систем управления и методологий управления проектами. Японцы знают, что такое менеджмент, и они знают, зачем нужно следить за договоренностями.
К сожалению, в нашем обществе большинство людей еще не понимает, что можно разграничить преданность работе и личную жизнь за стенами офиса, без ущербов как первому так и второму. Некоторым все еще кажется что менеджмент это «когда за тобой следят», или «когда тебе не доверяют», и именно с этими предрассудками менеджерам и приходится бороться с самого первого дня проекта.
Для более детального понимания того, о чем я говорил в части подведения итогов, могу порекомендовать прочесть небольшую книжку Кеннета Бланшара и Спенсера Джонсона – Одноминутный Менеджер. Не смотря на свой размер, в книге действительно интересным образом развернуто все то, о чем я говорил в последних параграфах.
В следующей статье мы поговорим о философиях систем управления проектами. Мы также поймем разницу между философией, методологией и методом управления проектами.