Внутренние стандарты работы аналитиков: какие документы и правила дают эффект, а какие живут только в базе знаний
В базе знаний компании может лежать внушительный набор материалов для аналитиков: шаблоны ТЗ, правила оценки, инструкции по встречам, требования к протоколам, рекомендации по работе с требованиями и отдельные документы о взаимодействии с разработчиками и РП. Если смотреть только на эту базу, может показаться, что работа давно стандартизирована, но на практике оказывается, что один аналитик оформляет требования в Word, другой пишет их в карточке задачи, третий хранит важные договоренности в протоколах, а перед оценкой каждый сам решает, достаточно ли уже информации для разработчика.
Если обнаруживаются подобные несоответствия, и особенно если их много (а не какие-то единичные исключения), важно сначала посмотреть на сами стандарты, потому что между документом, который опубликован в базе знаний, и правилом, которое действительно встроено в ежедневную работу, есть большая разница.
Хороший внутренний стандарт - это не самый подробный документ, а тот, который помогает быстро принять конкретное решение в нужный момент. Если перед передачей задачи разработчику аналитик открывает короткий чек-лист и замечает, что не описал сценарий ошибки или права доступа, стандарт сработал; если тридцатистраничную методику вспоминают только во время аудита или при адаптации новичка, ее практическая ценность уже вызывает вопросы.
Чем документ проще, тем он полезнее
Если мы хотим готовить документацию, которая действительно будет полезна для аналитиков с практической точки зрения, то нужно не описывать общие принципы работы с требованиями или ведении проектов, а смотреть на то, какие вопросы возникают у них в ежедневной работе.
Допустим, аналитик закончил описание доработки и собирается передать ее разработчику. В этот момент ему вряд ли поможет десять страниц текста о качестве требований, зато короткая проверка вполне может быть полезной: описан ли основной сценарий, понятно ли поведение при ошибках, разобрана ли работа с существующими данными, указаны ли ограничения прав и можно ли по документу понять, что именно потом будет проверяться на приемке.
Похожая история возникает с оценкой. Формулировка «аналитик должен качественно подготовить задачу к оценке» звучит правильно, однако почти не помогает понять, готова ли конкретная задача к обсуждению, тогда как договоренность о том, что до оценки должны быть определены границы изменения, основные сценарии, затрагиваемые интеграции и открытые вопросы, уже дает сотруднику понятный ориентир.
Шаблон ТЗ должен помогать разбирать задачу
Шаблон технического задания необходимо составлять так, чтобы он не был избыточен и подходил для всех задач. Иначе мы получим ситуацию, в которой шаблон у нас есть, в нем очень много красиво оформленных пунктов, но большинство из них неприменимы к конкретной задаче (аналитик либо заполняет разделы фразами «не применяется» и «изменений нет», либо начинает удалять ненужные блоки, после чего документы снова выглядят по-разному).
Лучше подготовить такой вариант, чтобы шаблон задавал направление мысли, но не требовал механически заполнять одинаковый набор разделов: для одной доработки придется подробно разбирать права доступа, для другой основная сложность будет в расчете, а для третьей почти весь объем займет интеграция с внешней системой.
При этом базовые вещи можно закрепить для всех задач: из описания должно быть понятно, зачем изменение делается (т.е. цель доработки), что входит в его границы, как пользователь будет работать после доработки и по каким признакам результат можно принять (сценарий поведения).
Короткий чек-лист полезен, если привязан к конкретному этапу
Для повторяющихся операций лучше работают небольшие чек-листы, привязанные к понятному моменту: передача требований разработчику, отправка документа заказчику, подготовка оценки или проверка результата.
Здесь легко повторить ошибку больших регламентов, если постепенно превратить семь пунктов в сорок. Когда вопросов становится слишком много, человек уже не проверяет их осмысленно, а просто пробегает глазами, поэтому такие списки стоит время от времени чистить, оставляя только то, что действительно помогает ловить ошибки.
Правила хранения
Отсутствие договоренности о хранении рабочих материалов быстро приводит к знакомой картине, когда рядом существуют «ТЗ_финал», «ТЗ_финал2», «ТЗ_новое» и еще несколько файлов, причем никто уже не уверен, какой из них актуальный. Красивой структуры папок недостаточно, если сотрудники не понимают, где находится основной источник требований и куда должны попадать изменения после встреч.
Для аналитика намного полезнее простое правило: где лежит актуальная спецификация, где искать протоколы, каким способом фиксируются спорные решения и какой документ считается основным, если информация расходится. Например, протокол может зафиксировать согласованное изменение, однако после внесения правки в ТЗ именно спецификация должна стать рабочим описанием решения, иначе через несколько месяцев один сотрудник будет смотреть последний протокол, другой — последнюю версию ТЗ, а третий найдет письмо заказчика и будет считать актуальным его.
Протокол встречи нужен вместе с правилом, что происходит дальше
Фиксация договоренностей после встречи действительно полезна, однако сам по себе шаблон протокола еще не гарантирует, что информация потом не потеряется. Если аналитик подробно пересказывает ход разговора на нескольких страницах, а после публикации никто к этому тексту не возвращается, документ становится архивом встречи, а не рабочим инструментом.
После чтения протокола должно быть понятно, что решили, какие вопросы остались открытыми, кто должен выполнить конкретное действие, в какой срок и в каком документе будет отражено принятое изменение. Если на встрече поменяли требование, оно не должно навсегда остаться только в протоколе, потому что разработчик, который подключится к задаче через месяц, может этого обсуждения вообще не увидеть.
Стандарт начинает умирать, когда пытается предусмотреть все
Многие тяжелые регламенты когда-то начинались с понятной проблемы, однако затем после каждого нового случая в них добавляли исключение, пояснение или специальное правило, и через несколько лет простой порядок работы превращался в документ на сорок страниц, где найти ответ стало сложнее, чем спросить коллегу.
Если документ чаще используют как аргумент после проблемы, чем как подсказку до нее, я бы считала это поводом для переработки. Основное правило можно оставить в коротком рабочем формате, а подробные пояснения, примеры и редкие исключения вынести отдельно, чтобы они не мешали человеку быстро найти нужный ответ.
Стандарт должен быть рядом с той работой, которую регулирует
Представим, что в регламенте написано: перед передачей задачи разработчику аналитик обязан выполнить определенную проверку, однако в самой карточке задачи нет ни ссылки на чек-лист, ни другого напоминания. Получается, что сотрудник должен сам помнить о существовании правила, найти нужную страницу и применить ее именно в подходящий момент.
Пока команда небольшая и большинство сотрудников участвовало в создании стандарта, такая схема еще может работать, однако после роста подразделения она начинает зависеть от памяти и устных договоренностей. Поэтому основные рабочие стандарты лучше приближать к месту, где они нужны: если перед передачей задачи требуется проверка, чек-лист должен быть доступен там, где аналитик передает задачу, а актуальный шаблон не должен теряться среди нескольких похожих страниц инструкций и стандартов.
Документ без владельца быстро перестает быть надежным
Это правило я считаю одним из самых важных - у любого документа и процесса должен быть владелец. Причем, владелец должен не просто значиться номинально, а по факту исполнять свои обязанности по своевременной актуализации документации.
Ведь даже самый хороший стандарт со временем устаревает, потому что меняются инструменты, шаблоны задач, процессы согласования и сама организация работы. Если никто не отвечает за содержание документа, в базе знаний продолжает лежать инструкция, которая уже расходится с реальностью, а отличить ее от действующей по названию бывает трудно. И, естественно, нельзя требовать с сотрудников (будь то аналитики или разработчики), чтобы они придерживались в своей работе правил, которые очевидно устарели.
Как понять, что стандарт действительно работает
Качество базы знаний в компании не оценивается количеством страниц, потому что реальный результат лучше заметен в обычной работе. Если разные аналитики оформляют похожие задачи примерно одинаково, разработчик знает, где искать необходимые сведения, а новый сотрудник способен выполнить типовой сценарий без постоянных вопросов более опытному коллеге, значит подготовленные инструкции и стандарты действительно работают.
Есть и обратная проверка: полезный стандарт хорошо заметен в тот момент, когда его пропустили. Не прошли чек-лист — забыли сценарий, не перенесли решение из протокола в основной документ — получили две версии требований, не указали характер оценки — заказчик воспринял предварительную цифру как согласованный объем. Если же какой-то документ можно удалить из базы знаний и несколько месяцев никто не заметит его отсутствия, стоит честно спросить, участвует ли он еще в работе или его уже давно стоит аннулировать.
База знаний должна помогать работать, а не просто хранить правильные документы
Внутренние стандарты начинают действительно помогать аналитикам тогда, когда перестают восприниматься как отдельный слой методологии, который нужно изучать независимо от работы. В нужный момент сотрудник должен получать подходящий шаблон, короткую проверку или ясное правило, не вспоминая название регламента и не читая несколько страниц ради одного ответа.
Поэтому время от времени необходимо пересматривать базу знаний не с вопросом «все ли у нас описано», а с более практичной позиции: когда этим документом пользовались в последний раз и какое решение он помог принять. После такого просмотра часть материалов придется обновить, некоторые объединить, а несколько документов спокойно отправятся в архив, и это хороший результат, потому что несколько понятных правил, встроенных в реальные задачи, обычно дают больше пользы, чем большая методическая база, которую все однажды прочитали и после этого почти не открывали.