Ошибки организации фазы анализа
Иногда меня просят включиться в проект, на котором анализ пошел как-то не так. Обычно "как-то не так" - это уже достаточно запущенная ситуация, когда с одной стороны уже потрачено достаточно много времени на достижение результата, а с другой - результат, который позволял бы утверждать, что проект движется вперед, не получен. Заказчик, видя все это, подымает красный флаг о рисках. Руководитель проекта, видя флаг и понимая, что результата нет, начинает пытаться вытолкать аналитиков из, как ему кажется, топтания на месте.
Но на самом деле они не топчутся. Они мечутся. Причина этих метаний - отсутствие идеи, как правильно делать этот проект. Ими допущены ошибки в организации своей работы. О том и поговорим.
Но для начала рассмотрим контекст. В нем участвуют четыре основные фигуранта:
Во всей этой истории у аналитика есть три основных потока взаимодействия:
Не определяют глоссарий проекта
Это приводит к тому, что Аналитик и Заказчик разговаривают на разных языках и зачастую попросту не понимают друг друга. Ситуация особенно усугубляется тогда, когда на стороне Заказчика исторически устоялся свой личный глоссарий технических терминов, отличный от общепринятого.
Последствия этой ошибки очень тяжелые - тяжелые коммуникации, недовольство Заказчика командой аналитиков, неправильная трактовка задачи вплоть до абсолютного непопадания в потребности Заказчика.
Не определяют ожидания Заказчика от фазы анализа
Проблема заключается в том, что результаты анализа интересны Заказчику не как промежуточный результат, который он аппрувнет для того, чтобы Разработчик начал пилить.
Результаты анализа важны Заказчику потому, что они убеждают его в правильности принимаемых решений. А также позволяют убедить в правильности принимаемых решений стейкхолдеров на своей стороне. Это подразумевает определенный объем и формат информации, которую Заказчик желает получить в результате аналитической фазы.
Аналитик часто об этом забывает, хотя понимание этих потребностей решает две важные задачи: позволяет быть "на одной волне" с Заказчиком и позволяет оптимизировать работу под ожидания, исключая из скоупа работ "лишние движения".
Не согласовывают шаблоны артефактов, которые войдут в поставку
Согласовывать шаблоны важно по двум причинам:
Не пытаются прочитать риски Заказчика
Заказчиком движет желание получить эффективно работающий продукт. Все решения, даже самые абсурдные, Заказчик принимает в следствие искреннего стремления к заветной цели. И всегда эти решения мотивированы видением рисков, которые могут негативно сказаться на движении к этой цели.
Понимание этих рисков позволяет понимать поведение Заказчика и предугадывать его действия. А также принимать такие решения, которые минимизируют риски Заказчика.
Вот только не все аналитики уделяют этому внимание, ошибочно считая, что выявление рисков и управление ими - функция руководителя проекта.
Следствие этой ошибки - ошибочное мнение о неадекватности Заказчика.
Не заимствуют опыт предыдущих проектов
Как внутри проектной команды, так и за ее пределами могут быть люди, обладающие знаниями и опытом создания решений, подобных тому, что проектируется для Заказчика. Заимствование этого опыта позволяет существенно сократить затраты и сделать решение более совершенным и интересным.
Тем не менее зачастую аналитики пренебрегают этим и проектируют решение так, будто до них ничего не было. В этом нет ничего плохого за исключением того случая, когда у аналитика нет опыта создания подобных решений. В этом случае результатом его работы зачастую становится нечто простое и даже примитивное.
Ошибка существенно усугубляется случаем, когда на проекте нужна уникальная экспертиза. Почему-то многие аналитики уверены в том, что способны поднять уникальную тему за пару вечеров, проведенных в Интернете. Практика показывает, что это не так.
Выстраивают работу "тупо по процессу"
Еще одна очень распространенная ошибка. Ее причиной обычно является либо слабое знание методологий выполнения работ, либо непонимание того, как получить необходимый результат. И какой результат надо получить.
Это незнание / непонимание является причиной завышенных затрат на анализ, поскольку движение по шаблону как правило требует избыточного количества действий - невозможно оптимизировать свою работу, когда ты не понимаешь, почему ты ее делаешь именно так.
Когда ты знаешь, что ты должен получить в итоге, и как к этому можно прийти, ты можешь понять, что тебе нужно в начале.
Непонимание отправной точки, отсутствие собственных идей
Жесткая беда многих команд. Первая причина недовольства Закзачика.
Если до начала коммуникаций с Заказчиком аналитик не сформулировал свое видение задачи и не определил, что ему нужно на старте, то аналитическая фаза в глазах Заказчика начинается с метаний аналитика и запросов типа "дайте все, что у вас есть".
Первое, что приходит в голову, когда такое видишь - это неуверенность в надлежащей квалификации привлеченного специалиста.
Но в этом моменте есть еще одна тема - Заказчик ожидает, что привлекаемый аналитик внесет свой вклад в первоначальные идеи, что позволит создать более интересный продукт. Если он видит, что аналитик этого не делает, наступает разочарование.
Не определяют ожидания Разработчика от результатов анализа
Почти всегда аналитик забывает, что одним из ключевых стейкхолдеров для него является Разработчик.
Разработчику придется брать результаты анализа и на их основании создавать продукт. Каким бы гениальным не был аналитик, он никогда не сможет "вслепую" попасть в ожидания Разработчика, если только до этого не работал с ним раньше и не понимает его профессиональный профиль.
Следствием этой ошибки является непопадание в ожидания разработчика, необходимость переработки результатов анализа, большой объем коммуникаций с Разработчиком.
Пожалуй, это наиболее частые ошибки, которые мне доводилось видеть в последнее время. Наверное я ничего важного не забыл. Если забыл - добавлю :), пишите.
То, что написано выше - это результат некоторого обобщения. С одной стороны. А с другой - он очень предсказуем, если посмотреть на контекст работы аналитика в проекте. Более того - если перед тем, как начать работу, отрисовать свой контекст в конкретном проекте, решить возникшие вопросы и организовать аналитическую фазу так, чтобы она соответствовала этому контексту, то все вышеперечисленные проблемы удастся избежать или существенно минимизировать риск их возникновения.
Вот я искренне не понимаю, почему люди этого не делают.
Но на самом деле они не топчутся. Они мечутся. Причина этих метаний - отсутствие идеи, как правильно делать этот проект. Ими допущены ошибки в организации своей работы. О том и поговорим.
Но для начала рассмотрим контекст. В нем участвуют четыре основные фигуранта:
- Заказчик - под этим понятием мы будем подразумевать группу людей, которая заказала нам проект, готова консультировать нас по особенностям проекта, известным на их стороне, будет принимать результат нашей работы. Я воздерживаюсь от разделения роли Заказчик на такие роли, как Владелец, Спонсор, Консультант, Эксперт и т.п., поскольку это позволяет упростить все последующее повествование. Заказчик имеет по отношению к продукту определенные ожидания.
- Аналитик - специалист, который должен разработать требования к проектируемому продукту.
- Разработчик - специалист (группа специалистов), который должен на основании требований, сформулированных аналитиком, разработать продукт, который попадет в ожидания Заказчика.
- Руководитель проекта - специалист, обеспечивающий управление проектом в целом, включая координацию взаимодействия и решение эскалированных на него проблем.
Во всей этой истории у аналитика есть три основных потока взаимодействия:
- Первый поток - взаимодействие с Заказчиком. Его целью является сбор первичной информации и валидация результата разработки требований на предмет соответствия ожиданиям и потребностям Заказчика
- Второй поток - взаимодействие с Разработчиком. Цель этого потока - определение потребностей разработки в результатах анализа и обеспечивание разработки этими результатами.
- Третий поток - взаимодействие с руководителем проекта. Целями этого потока является синхронизация своих действий с общим движением проекта, эскалация проблем, которые нельзя решить на своем уровне, а самое главное - вселение в руководителя проекта уверенности в завтрашнем дне.
Не определяют глоссарий проекта
Это приводит к тому, что Аналитик и Заказчик разговаривают на разных языках и зачастую попросту не понимают друг друга. Ситуация особенно усугубляется тогда, когда на стороне Заказчика исторически устоялся свой личный глоссарий технических терминов, отличный от общепринятого.
Последствия этой ошибки очень тяжелые - тяжелые коммуникации, недовольство Заказчика командой аналитиков, неправильная трактовка задачи вплоть до абсолютного непопадания в потребности Заказчика.
Не определяют ожидания Заказчика от фазы анализа
Проблема заключается в том, что результаты анализа интересны Заказчику не как промежуточный результат, который он аппрувнет для того, чтобы Разработчик начал пилить.
Результаты анализа важны Заказчику потому, что они убеждают его в правильности принимаемых решений. А также позволяют убедить в правильности принимаемых решений стейкхолдеров на своей стороне. Это подразумевает определенный объем и формат информации, которую Заказчик желает получить в результате аналитической фазы.
Аналитик часто об этом забывает, хотя понимание этих потребностей решает две важные задачи: позволяет быть "на одной волне" с Заказчиком и позволяет оптимизировать работу под ожидания, исключая из скоупа работ "лишние движения".
Не согласовывают шаблоны артефактов, которые войдут в поставку
Согласовывать шаблоны важно по двум причинам:
- Заказчик понимает и одобряет объем и содержание информации, которую мы ему поставим
- У Заказчика формируется четкое представление, что именно он получит в результате анализа
Не пытаются прочитать риски Заказчика
Заказчиком движет желание получить эффективно работающий продукт. Все решения, даже самые абсурдные, Заказчик принимает в следствие искреннего стремления к заветной цели. И всегда эти решения мотивированы видением рисков, которые могут негативно сказаться на движении к этой цели.
Понимание этих рисков позволяет понимать поведение Заказчика и предугадывать его действия. А также принимать такие решения, которые минимизируют риски Заказчика.
Вот только не все аналитики уделяют этому внимание, ошибочно считая, что выявление рисков и управление ими - функция руководителя проекта.
Следствие этой ошибки - ошибочное мнение о неадекватности Заказчика.
Не заимствуют опыт предыдущих проектов
Как внутри проектной команды, так и за ее пределами могут быть люди, обладающие знаниями и опытом создания решений, подобных тому, что проектируется для Заказчика. Заимствование этого опыта позволяет существенно сократить затраты и сделать решение более совершенным и интересным.
Тем не менее зачастую аналитики пренебрегают этим и проектируют решение так, будто до них ничего не было. В этом нет ничего плохого за исключением того случая, когда у аналитика нет опыта создания подобных решений. В этом случае результатом его работы зачастую становится нечто простое и даже примитивное.
Ошибка существенно усугубляется случаем, когда на проекте нужна уникальная экспертиза. Почему-то многие аналитики уверены в том, что способны поднять уникальную тему за пару вечеров, проведенных в Интернете. Практика показывает, что это не так.
Выстраивают работу "тупо по процессу"
Еще одна очень распространенная ошибка. Ее причиной обычно является либо слабое знание методологий выполнения работ, либо непонимание того, как получить необходимый результат. И какой результат надо получить.
Это незнание / непонимание является причиной завышенных затрат на анализ, поскольку движение по шаблону как правило требует избыточного количества действий - невозможно оптимизировать свою работу, когда ты не понимаешь, почему ты ее делаешь именно так.
Когда ты знаешь, что ты должен получить в итоге, и как к этому можно прийти, ты можешь понять, что тебе нужно в начале.
Непонимание отправной точки, отсутствие собственных идей
Жесткая беда многих команд. Первая причина недовольства Закзачика.
Если до начала коммуникаций с Заказчиком аналитик не сформулировал свое видение задачи и не определил, что ему нужно на старте, то аналитическая фаза в глазах Заказчика начинается с метаний аналитика и запросов типа "дайте все, что у вас есть".
Первое, что приходит в голову, когда такое видишь - это неуверенность в надлежащей квалификации привлеченного специалиста.
Но в этом моменте есть еще одна тема - Заказчик ожидает, что привлекаемый аналитик внесет свой вклад в первоначальные идеи, что позволит создать более интересный продукт. Если он видит, что аналитик этого не делает, наступает разочарование.
Не определяют ожидания Разработчика от результатов анализа
Почти всегда аналитик забывает, что одним из ключевых стейкхолдеров для него является Разработчик.
Разработчику придется брать результаты анализа и на их основании создавать продукт. Каким бы гениальным не был аналитик, он никогда не сможет "вслепую" попасть в ожидания Разработчика, если только до этого не работал с ним раньше и не понимает его профессиональный профиль.
Следствием этой ошибки является непопадание в ожидания разработчика, необходимость переработки результатов анализа, большой объем коммуникаций с Разработчиком.
Пожалуй, это наиболее частые ошибки, которые мне доводилось видеть в последнее время. Наверное я ничего важного не забыл. Если забыл - добавлю :), пишите.
То, что написано выше - это результат некоторого обобщения. С одной стороны. А с другой - он очень предсказуем, если посмотреть на контекст работы аналитика в проекте. Более того - если перед тем, как начать работу, отрисовать свой контекст в конкретном проекте, решить возникшие вопросы и организовать аналитическую фазу так, чтобы она соответствовала этому контексту, то все вышеперечисленные проблемы удастся избежать или существенно минимизировать риск их возникновения.
Вот я искренне не понимаю, почему люди этого не делают.
