1. Предыстория
Шел 2006 год. Мой путь системного аналитика начался в очень большой компании с хорошо налаженным жизненным циклом разработки.
Аналитики, менеджеры проектов, программисты, тестировщики, архитекторы работали в компании уже не один год. Задолго до моего появления в команде, в компании был утвержден формат спецификации требований, для всех удобный, привычный и понятный.
Мне сказали: делай так, и будет всем счастье. И стало так… до релиза первого серьезного проекта. Там-то и выяснилось, что просто грамотно следовать шаблону, а затем согласовать документ с необходимым списком лиц — недостаточно.
А выяснила я это уже через пол года работы аналитиком.
Что же я делала целые пол года, спросите вы?
Мне поручали описание небольших изменений, о которых так или иначе все были в курсе еще до моего прихода в компанию. Специалисты знали, что надо будет сделать; грядущие проекты неоднократно обсуждались ранее. А спецификация требований была скорее «бумажкой» для сбора подписей. Подписанный документ служил отмашкой: «можно начинать, людей выделили, бюджет утвердили и проект начат» (это я сейчас это понимаю, но не тогда!).
Еще в мои обязанности входило описание стандартных задач (конфигурация или мелкие, простые изменения в системе). Такие требования тоже были всем понятны с полуслова. В общем, документ был напоминанием, что надо сделать, но никто не вчитывался особо.
И вот через пол года мне поручили непростую задачу. В начале проекта я, как обычно, встретилась несколько раз с представителем заказчика, мы обсудили необходимые изменения, я их описала, согласовала со всеми. Получив на титульной страничке необходимый набор подписей я, очень довольная проделанной работой, отдала документ менеджеру и благополучно ушла в отпуск. «Моя работа в данном проекте завершена» — думала наивная я, опираясь на опыт предыдущих мелких задач.
Вот тут-то и началось самое интересное. На глубине описанного мною уровня детализации всем все было понятно. Все поставили свои подписи на документе. И отдали в работу программистам и тестировщикам. Когда дело дошло до тестирования, я уже давно вернулась из отпуска и занималась следующей задачей, на которую была выделена на 100%. А ко мне начали приходить с вопросами тестировщики (первый раз в жизни!). Они нашли отличия между требованиями и реализацией (вот так сюрприз!).
В общем, один и тот же текст трактовался по-разному: мною, программистами и тестировщиками. Спасибо, хоть с заказчиками у меня видение совпало. Потом мы вместе отстаивали нужный вариант. Описано было так, что, копнув чуть глубже,
2. Какие я тогда выделила проблемные места
2.1. Качество спецификаций: требования были недостаточно конкретные. Была описана общая идея, при этом путей реализации можно было придумать несколько. А заказчику был важен конкретный вариант. Соответственно, нужно было либо очень подробно описать необходимое решение, либо ежедневно на этапе проектирования и реализации встречаться с командой, рассказывать, что требуется, смотреть, что получается. Учитывая бизнес процессы той компании, да еще и предстоящий отпуск, мне подошел бы первый вариант.
2.2. Участие аналитика в жизни проекта: я принимала участие только на начальных фазах жизненного цикла продукта. А аналитик нужен на всех этапах:
а) на фазе обсуждения бизнес идеи аналитик может подсказать:
— возможна ли реализация,
— способы и стоимость реализации.
б) фаза анализа и проектирования: ну, и так понятно;
в) фаза разработки и тестирования: отвечать на вопросы программистов и тестировщиков, активно принимать участие в обсуждениях. Тестировать, проверять реализацию основной функциональности. Просмотреть тест-кейсы или подсказать тестировщикам «хитрые» моменты, что нужно проверить. Всегда есть такие нюансы, что только аналитик держит в голове, а проверить их никому не приходит в голову :)
г) сдача в эксплуатацию и использование продукта: аналитик часто знает продукт лучше всех и может принять участие в подготовке презентаций продукта.
Если возникают вопросы или замечания во время эксплуатации, аналитик согласовывает и пишет требования к изменениям, при необходимости.
2.3. Согласование документа: практика показала, что подпись на документе (согласование документа) не всегда означает понимание требований подписываемым. Лучше лишний раз встретиться (хоть в скайпе) с теми, от кого что-то зависит и кому важны результаты проекта, провести презентацию и обсудить ключевые требования, если есть такая возможность. Убедиться, что вы «на одной волне».
И еще момент, который я хочу отметить сейчас, но тогда не задумывалась о нем.
2.4. Учет уровня команды и специфики проекта: этим злополучным проектом занимались новенькие в компании
разработчики и тестировщики. Если бы не этот нюанс, то, возможно, все прошло бы хорошо и для рассматриваемого проекта, даже без предыдущих пунктов.
Мораль: способ сбора и описания требований, а так же модель реализации проекта, зависит от конкретного проекта. Что необходимо учитывать:
— уровень команды;
— погружённость команды в проект;
— сработанность команды;
— тип задач (нечто стандартное для данной команды, конфигурация, либо сложный, уникальный проект);
— бюджет и сроки проекта;
— многое другое.
Но эта мысль посетила меня не сразу, и еще какое-то время я искала свою идеальную спецификацию.
3. Что я делала в сложившейся ситуации:
3.1. Много читала: в ход пошли Вигерс, Леффингуэлл, Коберн, и т.д. Я рассматривала примеры спецификаций, старалась почерпнуть максимум полезного и подходящего, и незамедлительно это использовала в работе.
3.2. Организовала своевременную обратную связь тестировщиков и программистов на ранних стадиях проекта:
менеджер проекта удивлялся, когда я просила выделить тестировщика для просмотра спецификации, но шел навстречу. Ведь есть такие вопросы, что приходят в голову только тестировщикам! И хорошо, когда они рассмотрены вовремя.
3.3. Собирала вместе кого-то из представителей заказчика, программистов, тестировщика, менеджера проекта перед запуском проекта: на такой встрече мы убеждались, что правильно понимаем друг друга, напоминали важные детали и т.п.
Спустя короткий период времени программисты стали отмечать прогресс и благодарить за спецификации.
И тут я поняла, что застопорилась на неком уровне и хочу двигаться дальше. У меня появилась навязчивая идея: узнать, как в других компаниях пишут спецификации, и почерпнуть что-то новое для себя. Нашлись форумы, сообщество аналитиков. Я читала «а как у других», рассматривала примеры, инициировала встречи и задавала вопросы.
Отдельно хочу отметить, что мир не без добрых людей, и малознакомые, но опытные аналитики ни разу мне не отказали во встрече и ответах на вопросы. Спасибо вам, дорогие коллеги. Поэтому, «ищите и найдете, стучите, и вам отворят».
Продолжение следует…
Комментарии (42)
SVVer
17.07.2015 13:08А какое отношение в описанной компании было к agile-технологиям разработки?
elena_g Автор
17.07.2015 14:04Здравствуйте!
Когда я там начинала работать, отношений с agile у компании не было. А в году 2010 или 11-м некоторые менеджеры проектов стали смотреть в сторону agile и пробовать на подходящих проектах.
AlexanderAnisimov
17.07.2015 16:18+1Мне одному кажется что существенную часть этих тайных знаний можно было почерпнуть меньше чем за год — внимательно изучив описания соответствующих вакансий на hh? Ну и Вигерса, да.
Крупная компания, которая в рамках своего «налаженного жизненного цикла» не предусматривает таких вещей как аналитическое сопровождение разработки и ставит джуниор-аналитика одного на достаточно весомую задачу, не дав ему хотя бы раз поработать в команде с более опытным наставником — это как-то не очень монтируется с налаженными процессами.
Я правильно понимаю что заказчики — госбюджетные?elena_g Автор
17.07.2015 16:25Здравствуйте!
Можно получать знания по-разному. Что-то с hh почерпнуть, что-то — на основании книг, опыта, ошибок.
Я поделилась ошибками и выводами первого полугодия работы. Кому-то может это пригодиться, кто-то научиться чему-то на моих ошибках. Буду рада.
u_story
17.07.2015 23:47А как вы проводите верификацию полученного продукта на соответствие результатам работы аналитика?
elena_g Автор
18.07.2015 11:15Добрый день!
Путем поддержки постоянной обратной связи с заказчиком.u_story
18.07.2015 11:42Заказчик документы ваши читает?
Или имеется в виду, что вы передаете все заказчику со словами — верифицируй?elena_g Автор
18.07.2015 15:17Прошу прощения, не так вопрос прочитала вначале.
Тестировщики этим занимаются: составляют тест-кейсы и тестируют.u_story
19.07.2015 10:47Т.е. вместе садитесь, проходите по документу и создаете планы тестирования?
Я думал, что, возможно, используете какие-нибудь хитрые инструменты по преобразованию требований в тесты.elena_g Автор
19.07.2015 23:42лично у меня не было опыта использования таких инструментов преобразования. Ну а план тестирования тестировщики сами составляли обычно, я могла просмотреть, ответить на вопросы при необходимости.
michael_vostrikov
19.07.2015 18:24+1А ко мне начали приходить с вопросами тестировщики (первый раз в жизни!). Они нашли отличия между требованиями и реализацией (вот так сюрприз!)
Предполагаю, что программисты тоже нашли отличия между требованиями и реализацией, потому как реализация это их работа. Или вернее, у них были вопросы, как именно реализовать конкретное требование. И они могли сообщить об этом гораздо раньше. Но они никому ничего не сказали, потому что:
— Их никто не спрашивал
— Это добавит им работы (за то же время и за те же деньги)
— Как скажут, так и переделаем (можно сделать и так и так без особых усилий)
По моему опыту, чаще встречается первый вариант, реже второй, иногда третий. Да, потом вопросы решаются; программистам говорят «надо сделать вот так»; просто реализация затягивается и время уходит. А можно было сразу спросить программистов (или архитекторов, если они есть)elena_g Автор
19.07.2015 23:34Здравствуйте, спасибо за комментарий!
Правды ради стоит сказать, что в описанной истории на документе таки была подпись руководителя программистов и (формально) вопросов у него не было.
Там именно некоторые требования звучали неконкретно, их можно было интерпретировать по-разному. Программистам все было понятно. Но поняли неправильно. Тестировщики интерпретировали их, как и я, а программисты иначе.
Но да, не могу не согласиться, что нужно программисто спрашивать, обсуждать требования. И об этом как раз пункты 3.2 и 3.3 в статье.
lair
«Но как, Холмс»?
Нам нужна система, которая будет обрабатывать сигналы о местоположении от 200+ тысяч пользователей и показывать их на карте с задержкой не более двух минут. Возможность, способы, стоимость?
elena_g Автор
Добрый день!
Отвечу на Ваш первый вопрос на основании личного опыта. Сталкивалась с 2-мя ситуациями:
1. Аналитик работает с системой, где требуются изменения (самая простая ситуация). Как правило, тут человек уже через несколько месяцев работы неплохо знает и предметную область, и возможности программистов, и архитектуру системы. Или знает, где подсмотреть, кого спросить. Может рассказать, что вот для этого изменения нужно доработать логику, для этого — менять архитектуру, но можно сделать что-то проще, но без изменений архитектуры, и т.п. По опыту знаю, что аналитик довольно быстро учится делать достаточно точные оценки в такой ситуации, если часто практикуется:)
2. Нужно сделать оценку для кардинально новой разработки. Аналитик изучает предметную область, советуется со специалистами, и после проделанной работы предлагает варианты заказчику. Учитывается множество факторов, возможные технологии. Что быстро сделать под iOS, под андроид сложнее, и наоборот :)
По поводу вашего второго вопроса: сходу не скажу, надо исследовать :) какая карта, платные или бесплатные возможности популярных карт? Какой сервер, какой канал, какая нагрузка? Пообщавшись с заказчиком и с экспертами, аналитик вам предложит варианты.
lair
На основании чего аналитик принимает решения, для чего нужно менять архитектуру, а для чего — нет, и какое изменение архитектуры «проще» или «сложнее»? Какую роль в команде играет архитектор?
Так аналитик может подсказать, или аналитик может посоветоваться со специалистами и транслировать их мнение?
Нагрузка озвучена, все остальное на ваше усмотрение. Интересуют возможные варианты с их плюсами/минусами и стоимостью.
elena_g Автор
Решения принимает на основании анализа системы (как ни банально это прозвучит), знаний и опыта. Бывают случаи (часто!), когда аналитик выполняет функцию архитектора. В разных проектах разное распределение ролей.
По поводу подсказать или транслировать: оба варианта имеют место быть. Глупо злоупотреблять опытом гуру. Иногда нужно собрать их мнение и транслировать заказчику, это тоже работа аналитика, он выступает звеном между заказчиками и разработчиками.
На счёт оценки системы: не могу сходу ответить. Оценка возможностей системы, существующих решений, уровня программистов и т.д. может занимать достаточно долгое время.
lair
Откуда у аналитика (особенно — бизнес-аналитика) опыт, скажем, в проектировании (ну там — протоколы, партиционирование, вся эта требуха) распределенных систем с совместной работой?
Я могу еще поверить в обратное (когда человек с основной ролью архитектора еще и выполняет роль аналитика); но надо понимать, в любом случае, что роли аналитика и архитектора фундаментально различны.
Это, извините, уже этап анализа. А вы написали, что аналитик может это подсказать на этапе обсуждения бизнес-идеи.
elena_g Автор
А откуда вообще берется опыт? (Риторический вопрос). Аналитику в принципе нужно много знать и уметь. Мне приходилось работать в компаниях, где роли аналитика и архитектора были совмещены. И знаю, что не только в тех компаниях так было.
На этап обсуждения бизнес-идеи уважающий себя аналитик приходит подготовленный. А если знания, опыта не хватает, чтоб сходу посоветовать, то не зазорно взять время и провести дополнительный анализ.
lair
Опыт берется из образования и проведенной работы. Надо просто помнить, что в голову к каждому человеку влезает не так много опыта, а работа аналитика сама по себе достаточно сложна, чтобы требовать full-time dedication.
Сколько книг по архитектуре ПО лично вы прочитали?
elena_g Автор
Книг достаточно прочитала, да и до аналитики немного работала в разработке и проектировании.
Но я Вас понимаю, лучше, когда есть и архитектор, и аналитик.
А вот на практике бывает иначе. В двух компаниях из четырех от меня требовали заниматься проектированием. Пришлось разбираться. И сейчас мне кажется, что даже хорошо, когда аналитик в состоянии копнуть немного глубже.
SVVer
А как вы разграничиваете роли аналитика, архитектора и проектировщика? Мне, честно говоря, тоже странно выполнение одним человеком ролей архитектора и аналитика одновременно. Я бы в этом случае предположил, что этот же человек и основной разработчик тоже.
lair
(достаточно? назовете хотя бы пару названий?)
Понимаете ли, я за свои сколько-то лет работы в отрасли не видел ни одного бизнес-аналитика, способного (а системных аналитиков не видел вообще ни одного живьем):
elena_g Автор
А мне вот доводилось таких встречать.
lair
Зачем им тогда архитекторы в команде?
Murlakatam
Я как аналитик, могу смело сказать — по тонкому льду идете Елена, с таким подходом.
Из моего опыта, такие решения мы принимаем командно, с привлечением и бизнеса и разработки. Причем, часто, предлагаемое изначально решение, в ходе дискуссии может сильно трансформироваться
elena_g Автор
Здравствуйте!
спасибо за Ваш опыт!
В моей практике простые или стандартные изменения оценивались аналитиками, более сложные — сообща. А вы все изменения командно оцениваете? Даже если заказчик просто узнает потенциальную возможность и примерные споки/влияние?
yuriy-s
Я интересовался ай-ти всю свою жизнь и начал программировать в детстве на вижуал Бейсике на украденном папой с работы компьютером в 10 лет. Потом в университете 4 года в веб тим пока получал BS, год в Микрософте на C++ перед окончательным уходом в консалтинг. MS CS топовой школы, полтора десятилетия работы программистом с множеством крупных и мелких клиентов, десяток стартапов долины. Web Developer => Sr Web Developer => Engineer => Full Stack => Team Lead => VP of Engineering => Architect.
Абсолютно не ради хвастовства, просто мне действительно интересно, каким образом вы можете делать ту работу к которой я шёл всю свою жизнь a именно решать что и как сделать и за сколько денег? Каким образом у вас может быть достаточно квалификации что бы предложить решение данной задачи «система, которая будет обрабатывать сигналы о местоположении от 200+ тысяч пользователей и показывать их на карте с задержкой не более двух минут.» Откуда вы знаете producer–consumer паттерн, дизайн API, решениями для big data и различием между способами хранения/аналитики этой даты?
yuriy-s
Ну а решение задачи выше может быть таким:
1. producer–consumer ( т.е. устройства пишут локально координаты с таймстемпом и шагом скажем 10 секунд и синхронизируются с сервером в бекграунде когда интернет есть и загрузка небольшая { device_id, lat, long, timestamp } )
2. К чёрту API, JSON и рукопожатия. UDP наше всё. Whatsapp таким образом миллионы(!) коннекшинов держит на одном сервере.
3. Elasticsearch для последних координат устройств ( и удобного гео-поиска с фильтрами ) и Cassandra для хранения всей истории перемещения ради последующей аналитики.
4. Ну допустим AWS
5. Google Maps For Work — $10K за год, Yandex ~ $6K. Покрытие Yandex в России хорошее а по миру не очень. OpenStreetMap бесплатно но из за ограничений по лимитам фиг сработает для 200К пользователей.
Kaiser
Поддерживаю.
Оценки сроков от аналитика одна из частых причин срывов сроков в проекте. Когда стал работать с «русским бизнесом» был неприятно удивлен распространенности этого явления. Хуже разве что архитектура от аналитика.
Здесь опыт нужен, чтобы в беседе с заказчиком определять проблемные места и подробнее доносить их до команды разработчиков. Тогда на встрече с разработчиками будет что обсудить: количество пользователей, лаг на карте, зачем нам все это нужно и какая у нас конечная цель, каковы критерии успеха. А не просто стоять человеком-телефоном и недоумевать.
Главное обходить 2 крайности:
— Заказчик часто озвучивает не функциональные требования, а свои представления о том, как это требование будет реализовано. Нужно уметь определить само требование.
— Заказчик лучше аналитика знает что ему нужно. Не стоит мнить себя мега-экспертом и делать «как лучше». Нужно делать как просят.
yuriy-s
Именно поэтому работа аналитика именно то что и подразумевает «бизнес аналитика» а именно формулировка задачи в более менее конкретных терминах ( например user stories или SRS ). Т.е. задачей аналитика как раз является встречи с клиентом в результате которого появляется формулировка «нужна система, которая будет обрабатывать сигналы о местоположении от 200+ тысяч пользователей и показывать их на карте с задержкой не более двух минут.» а ещё лучше подробности которые описанные в виде формального документа ( «нужна система ( что именно? код с установкой? поддержка? какие языки? какие версии контроля? ), которая будет обрабатывать сигналы (какие устройства? какие страны? ) о местоположении от 200+ тысяч ( с прицелом на будущее или нет ?) пользователей и показывать ( как показывать? веб? мобильные эппы? ) их на карте с задержкой не более двух минут.»
Т.е. идеальной работой аналитика является составление идеального документа который описывает задачу как можно подробнее. Именно саму задачу а не способы её решения. И цена, сроки, построение команды и архитектура это уже совсем другая квалификация и опыт.
elena_g Автор
Спасибо!
Каждый должен заниматься своим делом, и делать его хорошо, согласна.
Просто нет стандартной должностной инструкции аналитика. В зависимости от компании, от проекта, требования к такой роли варьируются. Часто происходит совмещение: аналитик+ПМ.
Где-то аналитик занимается только функциональными требованиями, где-то — проектирует БД, составляет use cases (в том числе и вызов нужных API на соответствующих шагах сценария), моделирует прототипы пользовательского интерфейса, описывает правила интеграции систем.
yuriy-s
Я считаю что да. Т.е. бизнес аналитика это именно общение с клиентом и перевод этого общения в формальные требования для разработки. PM тоже довольно часто ОК — в небольших компаниях это часто может делать один человек.
А вот архитектура/UX/DB это совсем не ОК. Без обид, но мнение разработчика ( если нет архитектора или тим лида ) тут более весомое чем ваше. Потому что более квалифицированное, конкретного опыта больше.
PM/Аналитик это медсёстра. Они должны померять температуру, распросить пациента и написать в карточку симптомы болезни, успокоить больного и сказать что всё будет хорошо. Разработчики это врачи ( каждый со своей специализацией, кто-то фронтэнд, кто-то бэкенд, кто-то выбирает мобильную разработку ), тим лид это заведующий отделом а архитектор это глав-врач. У каждого своя роль и свой необходимый уровень квалификации. Представляете что бы было если бы медсестра составляла план лечения сложных пациентов? Вы бы хотели бы лечится в такой больнице? :)
elena_g Автор
Еще раз повторюсь:)
Мнением архитектора и других специалистов никто не злоупотребляет.
Но, всё же, вы недооцениваете труд и знания аналитиков:) Тот же Вигерс (классика по требованиям) приводит в шаблоне спецификации требований такие разделы, как модель БД (логическая), требования к пользовательским и внешним интерфейсам, etc.
А еще часто залезть в БД, посмотреть на структуру, связи, атрибуты, а так же посмотреть код работающей системы — чуть ли не единственный источник требований. И об этом тоже пишут уважаемые авторы книг, по которым сдается сертификат по системному анализу. Наверное, мне стоило всюду в статье использовать термин «системный аналитик», а не просто аналитик.
Хотя, будем откровенны, у нас часто бизнес аналитиков называют системными и наоборот :)
lair
Между использованием структуры уже разработанной БД для понимания устройства системы, и предложениями заказчику новой структуры БД — гигантская дистанция.
И нет, мы не недооцениваем труд аналитиков, мы просто считаем, что и в их собственной области достаточно работы, чтобы не лезть в чужие.
PavelSandovin
Ну нет. Хороший PM/Аналитик это никак не медсестра. Это психотерапевт. А отличный PM/Аналитик — это психотерапевт, владеющий эриксоновским гипнозом.
elena_g Автор
Хорошая аналогия
Kaiser
Есть еще вопрос ответсвенности. Если я оценил что-то в 70-90 часов, то я должен успеть это в указанное время. Если не успел, то должен нести за это какую-то ответственность. Хотя бы в виде отчета «как так получилось и что нужно сделать, чтобы не случилось опять». Если успел раньше — все равно нужно понять что было не так с оценкой, чтобы следующая получилась точнее.
Оценил аналитик реализацию в 20 часов. Кто несет ответственность, если разработчик не успел? А еще сроки, спущены свыше, снижают мотивацию разработчика в них уложиться.
Общение с заказчиком — ok. Команда оценила требование в 700-900 часов, доносим это до заказчика. Возможно, ему на эти деньги требование окажется не нужным вовсе. Или решат упростить решение так, чтобы уложиться в 90 часов. Но это роль PM, а не аналитика.
Я допускаю, что один человек в команде может выполнять несколько ролей. Но только если он же несет ответственность за свои действия и обладает компетенцией.
elena_g Автор
Здравствуйте!
Спасибо за комментарий.
Правильно я понимаю вашу мысль, что аналитик должен заниматься только требованиями и не распыляться на другие задачи?
Так складывалось неднократно, что в мои обязанности, как аналитика, входила также и оценка сроков.
При необходимости, привлекала к этому процессу программистов, тестировщиков, админа, дизайнеров. Стандартные, несложные проекты сама могла оценить. К счастью, заказчики не жаловались.
elena_g Автор
Спасибо за ваш комментарий, за ваш опыт.
Действительно, если задача не стандартная, то я общаюсь с командой (и не только с программистами, а и с дизайнерами, тестировщиками). Мы совместными усилиями разрабатываем решение или варианты решений, после чего предложение озвучивается заказчику или менеджеру проекта.
Неужели так смутила фраза в статье, что аналитик принимает участие и на этапе обсуждения бизнес идеи, и что-то может подсказать?
Мне кажется, что это неплохой вариант, ведь аналитику потом писать требования, пусть будет в курсе с самого начала проекта.
Возможно, у вас другой опыт, процесс организован иначе. Я описала свой опыт.
yuriy-s
Нет, общение это нормально и обсуждение бизнес идеи тоже. Просто мне очень странно что по вашим словам вы имеете право конечного решения, организовываете встречи с кем считаете нужным ну и вообще getting things done. Точнее странно не это что вы это всё делаете а то что вы говорите что вы работаете Аналитиком а не Product Owner/ VP/ Architect. T.e. если вы имеете опыт для таких вещей и можете создавать достойные продукты, почему вы работаете аналитиком а не тем же архитектором с зарплатой в мин 2 раза больше?
elena_g Автор
Я описывала в статье свои первые шаги, как аналитика, ошибки и выводы. Но последние годы я работала БА + ПМ. На зп не жалуюсь:)