Разработка IT-проектов по современным методологиям предполагает наличие команды разработки, которая и является генератором получаемого клиентом решения.
В команде выделяются роли:
- собственно разработчика (человека, который пишет программный код);
- тестировщика (сотрудника, проверяющего итоговое решение на наличие ошибок);
- тимлида (лидера команды, управляющего всеми процессами в команде);
- продакт оунера (владельца продукта, ответственного за результат);
- системного аналитика (сотрудника, который определяет потребности пользователя, прорабатывает задачи до начала разработки и сопровождает разработку на всем протяжении жизненного цикла).
Аналитик переводит потребности бизнеса и пользователя на язык разработки, в результате чего разработчику становится понятна логика реализуемого решения; а пользователь получает именно тот продукт, который ему нужен.
За время работы в рамках проекта аналитик обрабатывает и накапливает огромный массив информации. Это совершенно естественно приводит к тому, что в эту “копилку знаний” регулярно заглядывают все члены команды, а иногда - и другие сотрудники организации.
Как аналитик может удержать хрупкое равновесие между задачами по созданию новых артефактов и необходимостью находиться в онлайн-режиме в течение всего рабочего дня? Попробуем разобраться.
С чего начнем?
Для начала поймем, в какой методологии производится разработка в данной команде.
Если команда работает по Waterfall`у или аналогичным последовательным методологиям, есть вероятность, что вопросов нам будут задавать меньше. Ведь здесь на аналитическом этапе мы готовим сложную большую постановку, в которой стараемся учесть все возможные вопросы и предусмотреть самые разнообразные варианты. Разработка по такой постановке предполагает четкое выполнение всего описанного, поскольку чаще всего итоговая задача “отшлифована” многочисленными согласованиями с заказчиками, менеджерами и другими заинтересованными лицами. Однако на другой чаше весов здесь - отсутствие регулярных встреч команды разработки, на которых оперативно решались бы все возникающие вопросы. Получается, что по этой конкретной постановке у команды разработки вопросы могут возникнуть только после того, как разработка начата. И именно тогда аналитику придется возвращаться к вопросам, которые уже “проварены” и слегка подзабыты.
Если команда работает по методологиям, основанным на философии Agile (Scrum, Kanban и др.), вопросов может возникать больше, поскольку в разработку поступают задачи различной степени детализации. Но ежедневные встречи, планирование, ретроспективы и другие предусмотренные методологиями мероприятия создают единое коммуникационное пространство, в рамках которого решаются возникающие у членов команды вопросы, происходит взаимный обмен информацией и формируется единое видение общих целей.
В любом случае мы видим, что время аналитика делится между временем, в которое мы занимаемся созданием уникальных артефактов (постановок, US, диаграмм, макетов, статей wiki и т.д.) и временем, в которое он занят задачами взаимодействия.
В данной ситуации можно порекомендовать несколько инструментов организации и структурирования своего рабочего времени.
Планируйте
Первым инструментом аналитика в борьбе за драгоценные минуты спокойной работы является планирование. Возможно, у вас возникнет закономерный вопрос или обоснованное возражение - как мы можем спрогнозировать время, которое потратим на консультирование команды разработчиков? Ведь в один день они могут не обратиться к нам вовсе, а в другой - задать вопрос, который требует полного включения и поиска дополнительной информации.
Я предлагаю вам подходить к планированию постепенно и взять полтора месяца на наблюдение. За это время в вашей команде разработки пройдет два-три спринта, а вы соберете достаточно данных для того, чтобы иметь возможность обоснованного планирования. Какие же моменты вам необходимо фиксировать в этот подготовительный период?
Во-первых, нужно составить список сотрудников, которые обращаются к вам за консультацией.
Во-вторых, необходимо ежедневно фиксировать количество поступающих от сотрудников вопросов и время, которое потребовалось вам на их решение.
В-третьих, вам нужно оценить примерную сложность возникающих вопросов, а также наличие ответов на них в описанных вами постановках и wiki-статьях.
По итогам подготовительного этапа у вас должна получиться таблица, содержащая примерно такие колонки:
- Номер итерации;
- Дата обращения;
- Время обращения;
- Время решения;
- Кто обратился;
- Роль обратившегося в проекте;
- Вопрос;
- Сколько времени занял ответ на вопрос;
- Есть ли ответ на вопрос в постановке/wiki.
Таким образом с незначительными временными затратами вы наберете прекрасную базу для дальнейшего прогнозирования.
Собранная информация поможет вам ответить на следующие вопросы:
- В какие дни недели ко мне чаще всего обращаются за консультациями?
- Какие сотрудники ко мне обращаются?
- Какие вопросы чаще всего встречаются?
- Сколько времени в день/неделю/итерацию/месяц я трачу на консультирование?
- Как активность коллег зависит от дня недели? От командных событий?
- Насколько критичны задаваемые мне вопросы?
- Читают ли члены команды внимательно мои постановки и wiki-статьи?
Уже догадываетесь, какие действия можно произвести с учетом имеющейся информации?
- Внести в план дни недели, в которые с 80% вероятностью вы сможете спокойно работать над своими задачами;
- Обратить особое внимание на представление задач тем сотрудникам, которые к вам обращаются чаще всего; проводить с ними предварительные плановые беседы, разъясняющие непонятные для них моменты в новых постановках;
- Составить список кратких ответов на наиболее часто встречающиеся вопросы и предоставить доступ к нему сотрудников. Сделать это нужно как можно быстрее, пока разработка функции еще не завершена. Этот список в дальнейшем послужит хорошей основой для wiki-статьи;
- Рассчитать среднее время, которое необходимо заложить на консультирование;
- Определить чисто для себя, что далеко не все задаваемые вопросы являются смертельными, и ответы на большинство из них можно дать не сиюминутно, а, например, спокойно закончив мысль или обработку блока информации;
- Поменять структуру и стиль изложения информации в базе знаний или постановке для наиболее легкого освоения читателями.
И уже после того, как все нужные приготовления произведены, - можете смело планировать будущую неделю. А в процессе работы, естественно, делать выводы о точности планирования и планировать будущие периоды точнее.
План может не быть подробным, но в нем должна содержаться информация о задачах, которые вы должны выполнить за эту неделю, и времени, которое вы можете выделить на задачи взаимодействия (в том числе - консультирование).
Поговорите с командой
Обозначьте свою позицию команде. Во время очередной встречи команды с участием тимлида (или без него, если вы работаете в классическом Scrum`е), - расскажите о том, что для более эффективной работы вам нужно время на полное погружение в вопрос. Объясните, что точно так же, как разработчикам тяжело “выныривать” из почти проработанного куска кода, - вам сложно отвлекаться от анализа определенной информации. И не забудьте упомянуть о том, что это может привести к снижению качества аналитики, создать риск упустить важную мысль. Просто поговорите, объясните это и совместно выработайте правила, по которым, например:
- до обеда вас лучше не тревожить;
- критичные срочные вопросы задавать лично, а не писать в чат;
- обращать внимание на текст постановки и прилагающиеся статьи wiki и в свободное время изучать их;
- в оговоренное время вы полностью доступны для входящих вопросов, готовы найти и предоставить всю необходимую информацию и т.д.
Список правил может быть каким угодно, главное - чтобы он подходил вам и команде.
Обратите особое внимание на то, что данные правила должны соблюдаться для всех членов команды.
Взращивайте идеи взаимного уважения - и тогда это будет работать.
Ешьте “помидоры”
Следующим инструментом является составление графика, по которому вы будете отвечать на накопившиеся к вам вопросы.
Например, вы с командой решили, что до обеда не отвечаете на их вопросы и полностью занимаетесь проработкой артефактов - поставьте это в график на день и не реагируйте на внешние раздражители.
Не отвлекаться на многочисленные чаты в процессе работы вам поможет, например, помидорковый таймер.
Например, заведите “помидор” на 25 минут, 25 минут спокойно поработайте. Через 25 минут сделайте себе приятное - уймите интеллектуальный зуд, почитайте все, что вам написали за это время в чатах, и запланируйте, когда сегодня вы будете отвечать на эти вопросы. Далее следуйте заложенному плану.
Ведите документацию
Еще один инструмент мы вскользь затронули выше - это база часто задаваемых вопросов и wiki проекта. Никто этого не читает - скажете вы. Даже постановки не все читают - скажете вы. Ну давайте, скажите, - все же так говорят! Вот же такой живой и теплый аналитик, а вот - бездушный, формализованный и совсем непривлекательный для чтения текст, - естественно, все выберут аналитика!
Наша задача - найти решение этой проблемы. Давайте добьемся того, что наши тексты начнут читать.
На предыдущих этапах вы отследили примерные пиковые периоды активности своих коллег (возможно, как гуру аналитики даже составили график) и осознали, какой информации им не хватает для работы. За время существования команды вы примерно выяснили, как именно мыслит ваша команда и поняли, что, например, картинки или схемы воспринимаются гораздо легче и проще и вызывают меньше вопросов, чем сплошной текст. То есть у вас есть все предпосылки для того, чтобы формировать контент исходя из особенностей вашей целевой аудитории.
Нарисуйте Mind Map; сделайте несколько слайдов презентации; киньте ссылку на написанную языком читателя wiki -статью в командный чат; расскажите о своих активностях и информации, которую можно найти на общекомандных ресурсах на ежедневном стендапе; подойдите к разработчику, который чаще всего к вам обращается и расскажите, где круглосуточно можно найти информацию…
В общем, выясните для себя индивидуально: что работает в вашей команде?
Итого
Как видите - рекомендации выше не содержат каких-то сложных методик и вы вполне можете применить их вне зависимости от стиля работы вашей команды.
Будем рады увидеть вашу обратную связь и почитать, что помогает структурировать рабочее время именно вам.
Текст: Татьяна Величкина
Редактор: Алена Черкасова
Фото: найдены на просторах Сети