keepsimple
dark
en | ru

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

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

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

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

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

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

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

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

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

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

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” широко распространена среди самых разных компаний как основной инструмент обеспечивающий коммуникацию.

Помимо него, так же широко используется другое приложение – Slack:

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

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

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

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

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

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

К примеру, если в команде несколько дизайнеров, и нам важно, чтобы дизайн материалы были собраны вместе – создаем папку дизайн и радуемся жизни. Ввиду того, что Google официально заявил о прекращении поддержки GDrive, мы можем смело посмотреть в сторону свободного ПО: OwnCloud.

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

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

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

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

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

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

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

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

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

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

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

Пример:

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

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

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

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

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

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

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