Отличия в работе аналитика в проектной и продуктовой разработке

Когда речь заходит о роли аналитика в IT, то всегда приходится добавлять кучу уточнений. Бизнес или системный аналитик? Анализ в продуктовой разработке или в проектной, как это, например, часто бывает в консалтинге? На внутренней разработке или на заказной?.. Заказчика государственного или негосударственного? И так далее.

В этой статье я рассмотрю, что меняется в голове специалиста и в рабочих процессах при смене формата деятельности на внутреннюю продуктовую разработку с проектной.

[sendpulse-form id=”278″]

О мнимых рамках при анализе

В заказной разработке (т.е. в реализации проекта под конкретные бизнес-задачи — чаще всего, но необязательно — с нуля) или на проектах внедрения существующих IT-решений, аналитики ограничены требованиями заказчика как первостепенного держателя компетенций в своём деле, эксперта в методологиях бизнеса и законодательства, либо ограничены возможностями стандартной функциональности внедряемых решений. В такой работе задача аналитика — предложить не слишком сложное для реализации решение, не ломая текущую архитектуру. И все это, я повторюсь, в рамках ограничений, накладываемых базовой функциональностью.

Эту фразу было довольно скучно читать. И это довольно узкое поле для творчества, не так ли? Тем не менее, творчество здесь присутствует, и ограничения могут послужить стимулом разработать весьма причудливые и при этом работающие механизмы!

Как это бывает в продуктах: в продуктовой разработке непросто переключиться на мысль, что можно придумать абсолютно все, что угодно. Приобретенные за годы инстинкты призывают действовать в рамках существующих решений. Ведь если дело касается собственного продукта, нужно подключать фантазию, выдавать варианты и альтернативы. Вплоть до создания новых процессов, функций и вообще изменения всего, чего угодно.

Борьба с этим рефлексом занимает некоторое время. Поначалу то и дело ловишь себя на мысли, что вокруг границы, границы, границы. Но границы эти только в голове.

В рамках работы над каждой задачей можно обсуждать возможные решения с командой, тимлидами и владельцем продукта (он же Product Owner, он же ПО), которые поощряют креативные идеи, даже если в итоге в разработку попадает наиболее простой вариант из предложенных. При необходимости можно собрать мозговой штурм — в том числе с коллегами из других подразделений, которые с удовольствием делятся своими наблюдениями и советами.

О зонах ответственности

В проектной работе, где всегда есть установленный Заказчик (сколько бы отдельных «подзаказчиков» не было в рамках Одного Большого), не приходится слишком много думать о том, зачем нужно то или иное требование. Заказчик сказал так-то и так-то, это не противоречит принятым бизнес-правилам, методологиям и доселе разработанной функциональности — значит так и надо. Не будет же Заказчик идти сам против себя и своего бизнеса! Таким образом, задача системного аналитика включает в себя больше описание бизнес-процессов, сбор и спецификацию требований, локальную проработку архитектуры и, возможно, документирование всего выше перечисленного.

В продуктах экспертиза зачастую находится внутри, и команда разработки, может, хочет и даже обладает карт-бланш на большую самостоятельность для проработки решений. Новый важный вопрос — можно ли что-то концептуально сделать иначе, другим способом? Точно ли есть необходимость? Как ещё можно решить задачу, проблему, боль и потребность? Точно ли это оптимальный вариант, и будет ли он полезен пользователям и бизнесу? Точно ли мы поможем кому-либо своим решением? Вот те вопросы, о которых аналитику (да и другим участникам команды), задумывается еще в самом начале анализа. Получается, в каком-то смысле, что команда разработки продукта наделена ощутимой силой при принятии решений, но, в то же время, и весьма большой ответственностью.

Заказчиком при продуктовой разработке — то есть голосом конечного пользователя — чаще всего выступает инициатор создания продукта (ПО). Но при этом он внимательно прислушивается к мнению команды разработки, хотя точка принятия решения находится именно на их стороне. Как говорится, один мозг — хорошо, а шесть — лучше. Именно поэтому иногда задачи обсуждают все вместе. В конце концов, разработчики, это пассажиры, которым так или иначе предстоит пользоваться продуктом.

Об анализе после анализа

Говоря о разных фреймворках и моделях процесса разработки программного обеспечения — таких как Waterfall, RUP и прочие, стоит помнить, что это не просто разные подходы и методики управления, это могут быть еще и принципиально разные культуры и паттерны поведения. Например, в консалтинге весьма привычна ситуация, когда при возникновении новых немаловажных требований или новых вводных (о которых забыли — такое бывает, проекты большие) подрядчик находит письмо, в котором вы договаривались о таком-то объеме и составе работ, а новые требования не обозначались в рамках плана. Такое письмо может служить официальным разрешением не принимать во внимание требования сейчас, отложить разработку на следующий этап проекта, в рамках новой задачи и за дополнительные средства. То есть, в крайних случаях, обязательства могут стоять выше разрешения боли заказчика — иначе границы проекта и плана могут разрастаться до бесконечности.

В Agile в целом (здесь я не настаиваю конкретно на продуктовой разработке), при появлении новых знаний можно, и часто даже нужно, переоценивать и менять поведение и план разработки. Даже если эта самая разработка уже в процессе, а то и завершилась вот только что. Да, это может быть не очень приятно, но это не должно быть катастрофой, в том числе для системного аналитика. Впрочем, важное замечание: не каждое новое требование обязано быть взятым в работу прямо сию минуту. Новые требования должны быть оценены и приоритезированы в карусели других задач (например, метод MoSCoW может быть в помощь).

Анализ нужно проводить как можно более полно перед началом разработки — это позволяет разработчикам заниматься вопросами своей области, а тестировщикам — в точности знать, как должна вести себя будущая функциональность. Однако, в связи с большим количеством стейкхолдеров и разнообразных перевозчиков, бывает, что новые приоритетные требования по задаче прилетают по факту.

В таких случаях можно действовать по ситуации: либо принять решение сейчас же изменить план разработки, даже если это не слишком удобно (если изменились внешние обстоятельства, например, появились новые требования перевозчиков с определенным сроком), либо сделать некоторый конечный вариант без новых требований, но обязательно поставив задачу с новым требованием на ближайший спринт-два. Таким образом мы играем с балансом скорости/качества анализа в рамках здравого смысла.

О «техническом задании» и документации

Уже сейчас существует десяток-другой способов оформлять и хранить проектную документацию. О, эти требования к проектной документации и её структуре… Аналитиков любят набирать со знанием стандартов ГОСТ 19, ГОСТ 34. Методология Oracle AIM предлагает десяток-другой шаблонов различных видов документов: функциональный дизайн, каталог настроек, библиотека ролей, все шаблоны утверждены и прокодированы. Документация держится в актуальном состоянии, любой сотрудник может обратиться к любому документу и поправить там что угодно (безусловно, с указанием авторства, заявки и характера изменений). А если это всё вовремя «не поддержать» — зачтут ли доработки при аудите трудозатрат?

Но вот есть свой продукт и внезапно — ты хозяин сам себе и своей базе знаний. Потрудишься над описанием процессов, продуктов, функциональности, требований — будет хорошо. Плохо напишешь — плохо потом будет людям, которым эти тексты с требованиями и описаниями понадобятся, в том числе, тебе самому. Несмотря на то, что никто не будет стоять с ружьем у виска и заставлять под страхом смерти писать тексты по ГОСТу, в твоих интересах знания задокументировать и сделать это оптимально (таким образом, как это удобно тебе и всем).

Для ведения различных документов можно использовать Confluence и локальные стандарты аналитики, при этом сами задачи могут вестись в JIRA или YouTrack. О том, какой объем необходим и достаточен, договариваться лучше сообща: популярной в компании может быть lightweight-документация (без излишних подробностей), для некоторых команд описание требований должно быть сделано как можно более детально. Документы не являются инструментом согласования (как это бывает в заказной разработке), но позволяют сформировать полное понимание продукта и отдельных блоков функциональности как, командой разработки, так и внешним заинтересованным лицам (например, коллегам из других продуктов и отделов).

Гибкость против Паники

Иногда эта картинка из прошлого возникает и по сей день. Прилетает какой-то баг, и вот, нужно всё бросать, быстро за 10 минут рисовать логику и код, потом ещё 5 минут на тестирование и ещё 5 минут на установку на продакшен. А потом можно выдохнуть, если не прилетел еще один аналогичный баг. Который, скорее всего, прилетел… Вспомним еще про SLA по проектному договору, за нарушение которого можно оштрафоваться или получить нагоняй. А ещё пользователи переживают, не хочется их лишний раз волновать.

И ты остаёшься с этими доработками до полуночи, до часу ночи — пока системные администраторы не доберутся до домашних компьютеров и не зальют их на продуктивную базу, и ты не напишешь пользователям позднее письмо «всё исправили!». И по выходным то же самое…

Но нет. Всё же в продуктах по-настоящему блокирующие задачи, из-за которых нужно немного попаниковать, возникают весьма редко, ЕСЛИ речь не идёт о высоконагруженных продуктах, где цена простоя очень высока. В стандартной ситуации большинство багов (не утверждаю, что все) едва ли требуют решения здесь и сейчас, через одно мгновение: можно остановиться, выдохнуть, подумать о том, что и как мы правим. Задачам с проблемами чаще всего просто проставляют повышенный приоритет, и они идут без очереди относительно других задач плана или спринта, но при этом проходят в рамках регулярных релизов.

Таким образом, можно говорить, что есть различие не столько между проектами и продуктами (хотя и здесь оно есть), а между степенями нагруженности используемой функциональности со стороны пользователей, со стороны имеющегося объема данных.

Заключение

Что лучше — проекты или продукты? Здесь совершенно неуместны такие слова как «лучше» или «хуже», в этом IT-мире есть своё место как для одного, так и для другого. Стоит понимать особенности разных подходов, формировать корректные ожидания и рассматривать каждый проект/продукт индивидуально.  У каждого свой опыт, свой бэкграунд, свои ожидания от работы. У кого-то — продукты, а у кого-то — проекты.