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

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

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

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

К началу 20го века некоторые люди поняли, что полагаться на память и смекалку сотрудников – чрезвычайно наивно и опрометчиво (спасибо Фредерик Тейлор!). Тогда они стали записывать свои задачи на листах бумаги, прибивая гвоздями к стенам, для наглядности. Во второй половине 20го века японцы одними из первых поняли бездонный, колоссальный потенциал менеджмента в целом, и оптимизации процессов в частности. Тогда они решили в добровольно-принудительном порядке ввести жесткие системы управления на всех своих предприятиях. Одна из таких систем, упоминание о которой, кажется, обязательно для всех кто пишет книги о менеджменте – Канбан. Суть Канбан метода сводилась к тому, чтобы позволять сотрудникам предприятия (в частности - руководству) видеть текущий статус задач предприятия "в реальном времени". Для этого в самом центре (или у самой дальней стены) завода помещалась огромная доска, на которой специальный "менеджер" двигал огромные карточки с текстом-названием задачи. Компания Toyota работала над этим три года (это около тысячи дней, ага), и к 1962-му году, видимо, окончательно убедившись в его безусловной эффективности начала перевод всех своих производственных линий на Канбан.

По мере развития информационных технологий, менеджерами в IT-компаниях разрабатывались все новые и новые методы для управления и кординации деятельности IT-команд. В ход шли разные схемы печатающиеся на листах бумаги формата А-3 – А-4. С 80х все стали активно использовать ставшие мейнстримом стикеры-задачи (post-it notes), а в начале 2000х начались активные эксперементы с самыми разными фремворками.

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

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

Теперь посмотрим пример такого ПО.

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

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

1. Координация.

Итак, начнем с простого, но популярного инструмента – Asana.

Скриншот с проекта разработки крупного портала киберспорта (eSports):

Инструмент дает возможность создавать списки, разделять их по заголовкам (1), добавлять задачи (одна строка = одна задача), отмечать решенные (5), назначать ответственных за задачу (6) и многое другое.

То, что система не дает по умолчанию, но что мы придумали для удобства:

Мы использовали префиксы – условные обозначения, которые были уникальны в рамках нашего проекта и которые давали возможность участнику быстро понять к чему относится задача. Так, префикс [IMPV] (2) мы приписывали к задачам, которые являлись совершенствованием уже существующего функционала. Префикс [Portal] (3) подчеркивал что речь идет о веб-платформе а не мобильном приложении (которое тоже было в разработке). Префикс [Player] указывал нам к какой странице вебсайта относилась задача (в нашем случае речь шла о Player Profile Page). Баги же мы помечали простым префиксом [BUG] (7). Все понятно, все просто.

Тот же проект, утилизированная доска в Trello:

Trello оперирует несколько иными понятиями: Лист (List) – обозначение колонки. Карточка (Card), Labels (Цветные маркеры на карточках), Powerups (Расширения, в основном, сторонних разработчиков, позволяющие добавить новый функционал к доске).

Backlog лист, куда помещались все задачи необходимые для имплементации;
In Progress лист, куда перемещались задачи, которыми разработчики занимались в реальном времени;
In Testing лист, куда перемещались задачи для тестирования командой тестировщиков;
Done лист, куда перемещались уже решенные задачи;
Префиксы, которые мы использовали. В частности, префикс [NEW] означал, что эта задача связана с новой фичей проекта, [Blocker] означал, что эту фичу необходимо имплементировать до запуска проекта в онлайн, [CMS] (7) – что задача связана с системой управления содержимым (Content Management System), а префикс [News] – что задача связана с дистрибуцией новостей на портале;
Системная иконка Trello, показывающая, что в карточке есть описание (доступное по клику);
Системная иконка Trello, показывающая, что к карточке прикреплены файлы;
Посредством PowerUp-а “Custom Fields” мы добавили внешние индикаторы для разделения Frontend и Backend задач которыми занимались разные разработчики. Да, мы могли использовать префикс и для этого, но в какой-то момент мы посчитали что так будет удобнее и сошлись на этом;
Системная иконка Trello, показывающая, что в карточке есть комментарии участников проекта;
Системная иконка Trello, показывающая, что в карточке есть чеклист;
Оранжевый лейбл, которым помечались задачи связанные с визуальным оформлением.

Другой проект, в рудиментарном состоянии (первичные настройки):

В первой карточке прикреплен документ с описанием работ необходимых для выполнения. Бизнес-название документа “Scope of Work”, или короче – SoW. Это одно из названий документа, которым закрепляется перечень работ на который согласились обе стороны – заказчик, и исполнитель;
Здесь выписаны используемые цвета, их значения и аббревиатуры которые будут использоваться в рамках этого проекта. Например, для того, чтобы в UserStories не писать многострочные названия ролей конечных пользователей, типа As Project Database Admin I want to… и далее, можно использовать APDBA I want to… и т.п.
В этой карточке прикреплены все материалы связанные с дизайном, чтобы команда работающая над проектом не терялась в почтах и ссылках в поисках разных файлов типа шрифтов, картинок, логотипов, инструкций и т.д;
Здесь дополнительные инструкции связанные с ведением проекта для общего ознакомления всех участников;
Лист с Эпиками;
Пользовательские Истории составленные на основе Эпиков;
Задачи, составленные на основании Историй (В нашем случае, команда еще не успела составить перечень задач).

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

И напоследок JIRA:

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

Названия листов. В «NEW» добавляется новый запрос, во второй колонкепроводится проверка актуальности запроса и возможности его реализации. В третьей колонке оцениваются сроки выполнения, и так далее;
Кол-во объектов в колонке;
Участники проекта имеющие доступ к этой доске;
Задача;
Приоритет задачи;
Кол-во дней сколько задача находится в колонке;
Установленный срок выполнения задачи;
Лицо, ответственное за выполнение;
Название задачи;
Порядковый номер задачи в формате аббревиатура:номер (ABC-25).

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

2. Коммуникация

Безусловно одним из самых популярных средств в наши дни является Skype. Его версия “Skype for Business” широко распространена среди множества крупных компаний. Другие популярные приложения: Zoom, Microsoft Teams, Google Meet, Google Hangouts, и конечно же Slack.

Slack:

Показывает доступные рабочие пространства (Workspaces), так, можно одновременно находиться в множестве workspace-ов с разными командами, проектами и задачами;
Название текущего рабочего пространства;
Каналы связи, обычно создаваемые для тематических обсуждений. Так, у нас есть канал который называется #yerevan-random для неформального общения (типа скидывания музыкальных треков и т.п.), и еще один канал #yerevan-announcements в котором публикуются важные оповещения;
Каналы обозначенные решеткой (#) – публичные; каналы с замком - приватные;
Список всех участников рабочего пространства, где каждый может написать кому угодно напрямую.
Поиск сообщений. Работает как в частных беседах так и в групповых чатах.

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

3. Обмен файлами

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

Любой проект подразумевает кооперацию с разными людьми, у которых свои собственные задачи и собственные методы работы. Кратчайший путь решения вопроса обмена файлов - создание папок в Dropbox или Google Drive.

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

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

Подведем итоги.

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

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

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

По сути это парадокс. С одной стороны, вроде бы все очень заинтересованы в успехе проекта, иначе он бы и не начинался, однако с другой стороны, часто, договоренности трактуются людьми как «нападки на их эго» и «посягательство на их свободу». Так, разработчик может «забыть» переносить завершенные задачи в колонку "Завершеныне задачи" на доске аппелируя тем, что у него «нет времени на перетаскивания карточек на доске» и что «писать код важнее». Дизайнер может сказать что «мне просто так не удобно работать, моя работа подразумевает вдохновение а не галочки в JIRA нажимать» и так далее.

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

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

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

В рабочем процессе не должно быть исключений для кого бы то ни было.

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

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

Пример:

Япония. О преданности японцев своей работе ходят легенды.

Экономически активное население этой страны: 65 миллионов человек.

Это одна из сильнейших экономик в мире стабильно находящаяся на 4м месте после Китая (1.3+ миллиарда человек), США (300+ миллионов человек) и Индии (1.3+ миллиарда человек).

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

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

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

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