5 различий работы аналитика в проектах и продуктовой разработке

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

    До прихода в Туту.ру я работала в IT-консалтинге на ERP-проектах и в заказной продуктовой разработке, здесь же я занимаюсь системным анализом во внутреннем продукте «Авиа». Отдел системного анализа у нас состоит из 9 аналитиков и 1 технического писателя. Далее на своем опыте я расскажу, что меняется в голове специалиста и в рабочих процессах при смене формата деятельности на внутреннюю продуктовую разработку с точки зрения анализа, а заодно поделюсь, как устроен процесс в целом у нас в Туту.ру.


    1. Добби свободен! О мнимых рамках при анализе


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

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

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

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

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

    2. Немного о зонах ответственности


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

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

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



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


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

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

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

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

    4. Пара слов о «техническом задании» и документации


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

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

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

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


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

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

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

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

    Хотя, признаюсь вам честно: иногда срабатывает какой-то давно забытый рефлекс — вот, нужно на прод прямо сейчас, прямо через 10 минут!

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



    ***


    Что лучше — проекты или продукты? Здесь совершенно неуместны такие слова как «лучше» или «хуже», в этом IT-мире есть своё место как для одного, так и для другого. Стоит понимать особенности разных подходов, формировать корректные ожидания и рассматривать каждый проект/продукт индивидуально. В общем, я свой выбор сделала, но совершенно его не навязываю. У каждого свой опыт, свой бэкграунд, свои ожидания от работы. Я — про продукты, а вы — решайте сами.
    Туту.ру 525,00
    Tutu.ru — сервис путешествий №1 в России.
    Поделиться публикацией
    Комментарии 4
      0
      ИМХО, в терминах PMBoK или IPMA «управление продуктом» неплохо ложится на «управление программой».
        0
        Уже считается, что именно так — Agile at Scale и управления проектами выравниваются. На последнем AnalystDays был доклад от иностранцев на эту тему. Ну и хорошее видео на эту тему со стороны Agile@Scale.
          0
          Здорово, конечно написано, как здорово там работать.
          Вопрос может не по теме, но очень интересно узнать: HR никогда не даёт обратной связи после первого с ним собеседования? Ни по телефону, ни по почте не отвечает?
            0
            Игорь, очень просим прощения! Передам в HR о Вашем запросе.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое