Хочу поделиться с вами правдивой историей о начале становления меня, как аналитика. Надеюсь, информация и выводы будут полезны начинающим системным аналитикам, бизнес-аналитикам.
Шел 2006 год. Мой путь системного аналитика начался в очень большой компании с хорошо налаженным жизненным циклом разработки.
Аналитики, менеджеры проектов, программисты, тестировщики, архитекторы работали в компании уже не один год. Задолго до моего появления в команде, в компании был утвержден формат спецификации требований, для всех удобный, привычный и понятный.
Мне сказали: делай так, и будет всем счастье. И стало так… до релиза первого серьезного проекта. Там-то и выяснилось, что просто грамотно следовать шаблону, а затем согласовать документ с необходимым списком лиц — недостаточно.
А выяснила я это уже через пол года работы аналитиком.
Что же я делала целые пол года, спросите вы?
Мне поручали описание небольших изменений, о которых так или иначе все были в курсе еще до моего прихода в компанию. Специалисты знали, что надо будет сделать; грядущие проекты неоднократно обсуждались ранее. А спецификация требований была скорее «бумажкой» для сбора подписей. Подписанный документ служил отмашкой: «можно начинать, людей выделили, бюджет утвердили и проект начат» (это я сейчас это понимаю, но не тогда!).
Еще в мои обязанности входило описание стандартных задач (конфигурация или мелкие, простые изменения в системе). Такие требования тоже были всем понятны с полуслова. В общем, документ был напоминанием, что надо сделать, но никто не вчитывался особо.
И вот через пол года мне поручили непростую задачу. В начале проекта я, как обычно, встретилась несколько раз с представителем заказчика, мы обсудили необходимые изменения, я их описала, согласовала со всеми. Получив на титульной страничке необходимый набор подписей я, очень довольная проделанной работой, отдала документ менеджеру и благополучно ушла в отпуск. «Моя работа в данном проекте завершена» — думала наивная я, опираясь на опыт предыдущих мелких задач.
Вот тут-то и началось самое интересное. На глубине описанного мною уровня детализации всем все было понятно. Все поставили свои подписи на документе. И отдали в работу программистам и тестировщикам. Когда дело дошло до тестирования, я уже давно вернулась из отпуска и занималась следующей задачей, на которую была выделена на 100%. А ко мне начали приходить с вопросами тестировщики (первый раз в жизни!). Они нашли отличия между требованиями и реализацией (вот так сюрприз!).
В общем, один и тот же текст трактовался по-разному: мною, программистами и тестировщиками. Спасибо, хоть с заказчиками у меня видение совпало. Потом мы вместе отстаивали нужный вариант. Описано было так, что, копнув чуть глубже,каждый плохо знакомый с процессами компании специалист мог найти то, что ему было удобнее/понятнее. Я была в шоке. Но быстро оправилась, «намотала эту ситуацию на ус» и провела работу над ошибками.
2.1. Качество спецификаций: требования были недостаточно конкретные. Была описана общая идея, при этом путей реализации можно было придумать несколько. А заказчику был важен конкретный вариант. Соответственно, нужно было либо очень подробно описать необходимое решение, либо ежедневно на этапе проектирования и реализации встречаться с командой, рассказывать, что требуется, смотреть, что получается. Учитывая бизнес процессы той компании, да еще и предстоящий отпуск, мне подошел бы первый вариант.
2.2. Участие аналитика в жизни проекта: я принимала участие только на начальных фазах жизненного цикла продукта. А аналитик нужен на всех этапах:
а) на фазе обсуждения бизнес идеи аналитик может подсказать:
— возможна ли реализация,
— способы и стоимость реализации.
б) фаза анализа и проектирования: ну, и так понятно;
в) фаза разработки и тестирования: отвечать на вопросы программистов и тестировщиков, активно принимать участие в обсуждениях. Тестировать, проверять реализацию основной функциональности. Просмотреть тест-кейсы или подсказать тестировщикам «хитрые» моменты, что нужно проверить. Всегда есть такие нюансы, что только аналитик держит в голове, а проверить их никому не приходит в голову :)
г) сдача в эксплуатацию и использование продукта: аналитик часто знает продукт лучше всех и может принять участие в подготовке презентаций продукта.
Если возникают вопросы или замечания во время эксплуатации, аналитик согласовывает и пишет требования к изменениям, при необходимости.
2.3. Согласование документа: практика показала, что подпись на документе (согласование документа) не всегда означает понимание требований подписываемым. Лучше лишний раз встретиться (хоть в скайпе) с теми, от кого что-то зависит и кому важны результаты проекта, провести презентацию и обсудить ключевые требования, если есть такая возможность. Убедиться, что вы «на одной волне».
И еще момент, который я хочу отметить сейчас, но тогда не задумывалась о нем.
2.4. Учет уровня команды и специфики проекта: этим злополучным проектом занимались новенькие в компании
разработчики и тестировщики. Если бы не этот нюанс, то, возможно, все прошло бы хорошо и для рассматриваемого проекта, даже без предыдущих пунктов.
Мораль: способ сбора и описания требований, а так же модель реализации проекта, зависит от конкретного проекта. Что необходимо учитывать:
— уровень команды;
— погружённость команды в проект;
— сработанность команды;
— тип задач (нечто стандартное для данной команды, конфигурация, либо сложный, уникальный проект);
— бюджет и сроки проекта;
— многое другое.
Но эта мысль посетила меня не сразу, и еще какое-то время я искала свою идеальную спецификацию.
3.1. Много читала: в ход пошли Вигерс, Леффингуэлл, Коберн, и т.д. Я рассматривала примеры спецификаций, старалась почерпнуть максимум полезного и подходящего, и незамедлительно это использовала в работе.
3.2. Организовала своевременную обратную связь тестировщиков и программистов на ранних стадиях проекта:
менеджер проекта удивлялся, когда я просила выделить тестировщика для просмотра спецификации, но шел навстречу. Ведь есть такие вопросы, что приходят в голову только тестировщикам! И хорошо, когда они рассмотрены вовремя.
3.3. Собирала вместе кого-то из представителей заказчика, программистов, тестировщика, менеджера проекта перед запуском проекта: на такой встрече мы убеждались, что правильно понимаем друг друга, напоминали важные детали и т.п.
Спустя короткий период времени программисты стали отмечать прогресс и благодарить за спецификации.
И тут я поняла, что застопорилась на неком уровне и хочу двигаться дальше. У меня появилась навязчивая идея: узнать, как в других компаниях пишут спецификации, и почерпнуть что-то новое для себя. Нашлись форумы, сообщество аналитиков. Я читала «а как у других», рассматривала примеры, инициировала встречи и задавала вопросы.
Отдельно хочу отметить, что мир не без добрых людей, и малознакомые, но опытные аналитики ни разу мне не отказали во встрече и ответах на вопросы. Спасибо вам, дорогие коллеги. Поэтому, «ищите и найдете, стучите, и вам отворят».
Продолжение следует…
1. Предыстория
Шел 2006 год. Мой путь системного аналитика начался в очень большой компании с хорошо налаженным жизненным циклом разработки.
Аналитики, менеджеры проектов, программисты, тестировщики, архитекторы работали в компании уже не один год. Задолго до моего появления в команде, в компании был утвержден формат спецификации требований, для всех удобный, привычный и понятный.
Мне сказали: делай так, и будет всем счастье. И стало так… до релиза первого серьезного проекта. Там-то и выяснилось, что просто грамотно следовать шаблону, а затем согласовать документ с необходимым списком лиц — недостаточно.
А выяснила я это уже через пол года работы аналитиком.
Что же я делала целые пол года, спросите вы?
Мне поручали описание небольших изменений, о которых так или иначе все были в курсе еще до моего прихода в компанию. Специалисты знали, что надо будет сделать; грядущие проекты неоднократно обсуждались ранее. А спецификация требований была скорее «бумажкой» для сбора подписей. Подписанный документ служил отмашкой: «можно начинать, людей выделили, бюджет утвердили и проект начат» (это я сейчас это понимаю, но не тогда!).
Еще в мои обязанности входило описание стандартных задач (конфигурация или мелкие, простые изменения в системе). Такие требования тоже были всем понятны с полуслова. В общем, документ был напоминанием, что надо сделать, но никто не вчитывался особо.
И вот через пол года мне поручили непростую задачу. В начале проекта я, как обычно, встретилась несколько раз с представителем заказчика, мы обсудили необходимые изменения, я их описала, согласовала со всеми. Получив на титульной страничке необходимый набор подписей я, очень довольная проделанной работой, отдала документ менеджеру и благополучно ушла в отпуск. «Моя работа в данном проекте завершена» — думала наивная я, опираясь на опыт предыдущих мелких задач.
Вот тут-то и началось самое интересное. На глубине описанного мною уровня детализации всем все было понятно. Все поставили свои подписи на документе. И отдали в работу программистам и тестировщикам. Когда дело дошло до тестирования, я уже давно вернулась из отпуска и занималась следующей задачей, на которую была выделена на 100%. А ко мне начали приходить с вопросами тестировщики (первый раз в жизни!). Они нашли отличия между требованиями и реализацией (вот так сюрприз!).
В общем, один и тот же текст трактовался по-разному: мною, программистами и тестировщиками. Спасибо, хоть с заказчиками у меня видение совпало. Потом мы вместе отстаивали нужный вариант. Описано было так, что, копнув чуть глубже,
2. Какие я тогда выделила проблемные места
2.1. Качество спецификаций: требования были недостаточно конкретные. Была описана общая идея, при этом путей реализации можно было придумать несколько. А заказчику был важен конкретный вариант. Соответственно, нужно было либо очень подробно описать необходимое решение, либо ежедневно на этапе проектирования и реализации встречаться с командой, рассказывать, что требуется, смотреть, что получается. Учитывая бизнес процессы той компании, да еще и предстоящий отпуск, мне подошел бы первый вариант.
2.2. Участие аналитика в жизни проекта: я принимала участие только на начальных фазах жизненного цикла продукта. А аналитик нужен на всех этапах:
а) на фазе обсуждения бизнес идеи аналитик может подсказать:
— возможна ли реализация,
— способы и стоимость реализации.
б) фаза анализа и проектирования: ну, и так понятно;
в) фаза разработки и тестирования: отвечать на вопросы программистов и тестировщиков, активно принимать участие в обсуждениях. Тестировать, проверять реализацию основной функциональности. Просмотреть тест-кейсы или подсказать тестировщикам «хитрые» моменты, что нужно проверить. Всегда есть такие нюансы, что только аналитик держит в голове, а проверить их никому не приходит в голову :)
г) сдача в эксплуатацию и использование продукта: аналитик часто знает продукт лучше всех и может принять участие в подготовке презентаций продукта.
Если возникают вопросы или замечания во время эксплуатации, аналитик согласовывает и пишет требования к изменениям, при необходимости.
2.3. Согласование документа: практика показала, что подпись на документе (согласование документа) не всегда означает понимание требований подписываемым. Лучше лишний раз встретиться (хоть в скайпе) с теми, от кого что-то зависит и кому важны результаты проекта, провести презентацию и обсудить ключевые требования, если есть такая возможность. Убедиться, что вы «на одной волне».
И еще момент, который я хочу отметить сейчас, но тогда не задумывалась о нем.
2.4. Учет уровня команды и специфики проекта: этим злополучным проектом занимались новенькие в компании
разработчики и тестировщики. Если бы не этот нюанс, то, возможно, все прошло бы хорошо и для рассматриваемого проекта, даже без предыдущих пунктов.
Мораль: способ сбора и описания требований, а так же модель реализации проекта, зависит от конкретного проекта. Что необходимо учитывать:
— уровень команды;
— погружённость команды в проект;
— сработанность команды;
— тип задач (нечто стандартное для данной команды, конфигурация, либо сложный, уникальный проект);
— бюджет и сроки проекта;
— многое другое.
Но эта мысль посетила меня не сразу, и еще какое-то время я искала свою идеальную спецификацию.
3. Что я делала в сложившейся ситуации:
3.1. Много читала: в ход пошли Вигерс, Леффингуэлл, Коберн, и т.д. Я рассматривала примеры спецификаций, старалась почерпнуть максимум полезного и подходящего, и незамедлительно это использовала в работе.
3.2. Организовала своевременную обратную связь тестировщиков и программистов на ранних стадиях проекта:
менеджер проекта удивлялся, когда я просила выделить тестировщика для просмотра спецификации, но шел навстречу. Ведь есть такие вопросы, что приходят в голову только тестировщикам! И хорошо, когда они рассмотрены вовремя.
3.3. Собирала вместе кого-то из представителей заказчика, программистов, тестировщика, менеджера проекта перед запуском проекта: на такой встрече мы убеждались, что правильно понимаем друг друга, напоминали важные детали и т.п.
Спустя короткий период времени программисты стали отмечать прогресс и благодарить за спецификации.
И тут я поняла, что застопорилась на неком уровне и хочу двигаться дальше. У меня появилась навязчивая идея: узнать, как в других компаниях пишут спецификации, и почерпнуть что-то новое для себя. Нашлись форумы, сообщество аналитиков. Я читала «а как у других», рассматривала примеры, инициировала встречи и задавала вопросы.
Отдельно хочу отметить, что мир не без добрых людей, и малознакомые, но опытные аналитики ни разу мне не отказали во встрече и ответах на вопросы. Спасибо вам, дорогие коллеги. Поэтому, «ищите и найдете, стучите, и вам отворят».
Продолжение следует…
