Когда речь идет о роли аналитика в ИТ, всегда приходится добавлять кучу уточнений.
Бизнес- или системный аналитик? Анализ в разработке продукта или в дизайне, как это часто бывает, например, в консалтинге? Собственная разработка или под заказ?.
Государственный или негосударственный заказчик? И так далее.
До прихода в Туту.
ру я работал в IT-консалтинге по ERP-проектам и разработке заказных продуктов, а здесь занимаюсь системным анализом во внутреннем продукте «Авиа».
Наш отдел системного анализа состоит из 9 аналитиков и 1 технического писателя.
Далее, исходя из своего опыта, я расскажу, что меняется в голове специалиста и в рабочих процессах при смене формата деятельности на внутреннюю разработку продукта с точки зрения анализа, а заодно поделюсь, как этот процесс целое работает на Туту.
ру.
1. Добби свободен! О мнимых рамках в анализе
При заказной разработке (т.е.при реализации проекта под конкретные бизнес-задачи – чаще всего, но не обязательно – с нуля) или в проектах по внедрению существующих ИТ-решений аналитики ограничены требованиями заказчика, поскольку основной обладатель компетенций в своей области, эксперт в области бизнес- и законодательных методологий, либо ограничены возможностями стандартного функционала внедряемых решений.
Для последних иногда выпускаются пакеты локализации (дополнительные части стандартного функционала, ориентированные на бизнес и законодательство в определенных регионах), что должно немного облегчить ситуацию, но, честно говоря, они не часто оказываются полезными.
В такой работе задача аналитика — предложить решение, которое не слишком сложно реализовать, не нарушая при этом текущую архитектуру.
И все это, повторюсь, в пределах ограничений, налагаемых базовым функционалом.
Согласен, читать это предложение было довольно скучно.
А это довольно узкое поле для творчества, не так ли? Однако креатив здесь присутствует, а ограничения могут послужить стимулом для разработки весьма причудливых механизмов, которые до сих пор работают! Как это было в продуктах : Когда я перешёл в разработку продуктов, мне было непросто переключиться на мысль, что я могу придумать абсолютно всё.
Приобретенные с годами инстинкты требовали действий в рамках существующих решений.
Ведь когда дело касается собственного продукта, нужно использовать воображение, придумывать варианты и альтернативы.
Вплоть до создания новых процессов, функций и вообще изменения чего-либо.
Борьба с этим рефлексом требует некоторого времени.
Поначалу то и дело ловишь себя на мысли, что вокруг есть границы, границы, границы.
Но эти границы только в голове.
Как это работает в Туту: В процессе работы над каждой задачей мы обсуждаем возможные решения с командой, тимлидами и владельцем продукта (он же Product Owner, он же ПО), которые поощряют творческие идеи, даже если в итоге самый простой вариант из предложенных оказывается в итоге разработка.
При необходимости мы можем организовать мозговой штурм, в том числе с коллегами из других отделов (например, из нашего контакт-центра или отдела поддержки продаж туров), которые с радостью поделятся своими наблюдениями и советами.
2. Немного о зонах ответственности
В проектной работе, где всегда есть устоявшийся Заказчик (сколько бы отдельных «субзаказчиков» ни было в рамках Одного Большого), зачастую не приходится особо задумываться, зачем нужно то или иное требование.Заказчик сказал то и это, это не противоречит принятым бизнес-правилам, методологиям и разработанному до сих пор функционалу — так и должно быть.
Заказчик не пойдет против себя и своего бизнеса! Таким образом, в задачу системного аналитика входит большее описание бизнес-процессов, сбор и уточнение требований, локальная проработка архитектуры и, возможно, документирование всего вышеперечисленного.
В продуктах экспертные знания часто находятся внутри компании, и мы, как команда разработчиков, можем, хотим и даже имеем карт-бланш для большей независимости в разработке решений.
Новый важный вопрос: можно ли что-то сделать концептуально по-другому, по-другому? Действительно ли есть необходимость? Как еще можно решить проблему, проблему, боль и нужду? Действительно ли это лучший вариант и принесет ли он пользу пользователям и бизнесу? Действительно ли мы помогаем кому-либо с нашим решением? Это вопросы, над которыми я, как аналитик (и другие члены команды), должен задуматься в самом начале анализа.
Получается, в каком-то смысле, я и мои коллеги наделены ощутимой властью в принятии решений, но, в то же время, очень большой ответственностью.
Как это работает в Туту: Клиентом, то есть голосом конечного пользователя, чаще всего является владелец продукта (программного обеспечения).
Но при этом наше программное обеспечение внимательно прислушивается к мнению команды разработчиков, хотя точка принятия решения на их стороне.
Как говорится, один мозг хорошо, а шесть лучше.
Поэтому иногда мы вместе обсуждаем задачи.
В конце концов, мы все не только разработчики, но и пассажиры, которые потом будут пользоваться готовым продуктом.
3. Об анализе за анализом
Говоря о разных фреймворках и моделях процесса разработки ПО — таких как Waterfall, RUP и других, стоит помнить, что это не просто разные подходы и методы управления, это также могут быть принципиально разные культуры и модели поведения.Например, в консалтинге очень распространена ситуация, когда при возникновении новых важных требований или новых затрат (о которых забыли - такое бывает, крупные проекты) подрядчик находит письмо, в котором вы договорились о таком-то объеме и объем работ, но никаких новых требований в плане не указано.
Такое письмо может служить официальным разрешением игнорировать требования сейчас, отложить разработку до следующего этапа проекта, в рамках новой задачи и за дополнительную плату.
То есть в крайнем случае обязательства могут наступить раньше решения боли заказчика — иначе границы проекта и плана могут расширяться до бесконечности.
В Agile в целом (здесь я не настаиваю конкретно на разработке продукта), при появлении новых знаний можно, а зачастую даже нужно переоценить и изменить поведение и план развития.
Даже если эта самая разработка уже ведется или даже только завершилась.
Да, это может быть не очень приятно, но это не должно стать катастрофой, в том числе и для системного аналитика.
Однако важное замечание: не каждое новое требование нужно учитывать прямо сейчас.
Новые требования следует оценить и расставить по приоритетам в карусели других задач (например, может помочь метод MoSCoW).
Как это работает в Туту: Мы стараемся провести максимально полный анализ перед началом разработки — это позволяет разработчикам разобраться с проблемами в своей области, а тестировщикам точно знать, как должен вести себя будущий функционал.
Однако из-за большого количества заинтересованных сторон и различных носителей случается, что новые приоритетные требования к задаче поступают постфактум.
В таких случаях мы можем действовать по ситуации: либо принять решение о немедленном изменении плана разработки, даже если это не очень удобно (если изменились внешние обстоятельства, например, появились новые требования перевозчиков с определенным сроком исполнения), или сделайте какую-то финальную версию без новых требований, но обязательно поставьте задачу с новым требованием на следующий-два спринта.
Таким образом, мы играем с балансом скорости/качества анализа в рамках здравого смысла.
4. Несколько слов о «технических характеристиках» и документации
Способов оформления и хранения проектной документации уже существует с десяток-два.Ох уж эти требования к проектной документации и ее структуре.
Любят набирать аналитиков со знанием стандартов ГОСТ 19, ГОСТ 34. Методология Oracle AIM предлагает десяток-два шаблона различных типов документов: функциональный дизайн, каталог настроек, библиотека ролей, все шаблоны утверждены и закодированы.
Документация поддерживается в актуальном состоянии; любой сотрудник может обратиться к любому документу и исправить там что угодно (разумеется, с указанием авторства, применения и характера изменений).
И если все это не будет «поддержано» своевременно, будут ли учтены улучшения при аудите затрат на оплату труда? Но вот оно у тебя есть.
ваш продукт и вдруг — ты хозяин себе и своей базе знаний.
Если вы усердно работаете над описанием процессов, продуктов, функциональности, требований, у вас все получится.
Если вы будете писать плохо, то будет плохо тем людям, которым будут нужны эти тексты с требованиями и описаниями, в том числе и вам самому.
Несмотря на то, что никто не будет стоять с пистолетом у виска и заставлять вас под страхом смерти писать тексты по ГОСТу, в ваших интересах документировать свои знания и делать это оптимально (так, как вам удобно) и все).
Как это работает в Туту: Для ведения различных документов мы используем Confluence и стандарты локальной аналитики, а сами задачи можно вести в JIRA. Договариваемся вместе, какой объем необходим и достаточен: несмотря на то, что в компании популярна облегченная документация (без лишних подробностей), для некоторых команд мы описываем требования более детально.
Документы не являются инструментом утверждения (как в случае с заказной разработкой), но позволяют сформировать полное представление о продукте и отдельных блоках функционала как нам, команде разработчиков, так и внешним заинтересованным сторонам (например, коллегам).
от других продуктов и отделов).
5. Гибкость против паники
Иногда эта картина из прошлого проявляется и по сей день.Прилетает какой-то баг, и теперь нужно все бросить, быстро нарисовать логику и код за 10 минут, потом еще 5 минут на тестирование и еще 5 минут на установку на продакшен.
И тогда можно выдохнуть, если не прилетел еще один подобный баг.
Которая, скорее всего, и поступила.
При внедрении того же учета каждый месяц прибывало несколько срочных, критических задач для исправления данных - данные нельзя было исправить вручную, и закрыть финансовый период с неверными данными в учете невозможно.
Также вспомним про SLA по проектному соглашению, за нарушение которого можно оштрафовать или получить нагоняй.
И пользователи тоже обеспокоены; Я не хочу их снова беспокоить.
И остаешься с этими модификациями до полуночи, до часу ночи - пока сисадмины не доберутся до домашних компьютеров и не загрузят их в продуктивную базу, а ты потом напишешь письмо пользователям: «все исправлено, можно закрывать!» » И в выходные то же самое.
Но нет. Еще в продуктах по-настоящему блокирующие задачи, по поводу которых нужно немного паниковать, возникают очень редко, ЕСЛИ мы не говорим о высоконагруженных продуктах, где стоимость простоя очень высока.
В стандартной ситуации большинство ошибок (я не говорю, что все) вряд ли требуют решения здесь и сейчас, в один момент: можно остановиться, перевести дух, подумать, что и как мы исправляем.
Задачам с проблемами чаще всего просто присваивается более высокий приоритет, и они выходят из последовательности относительно других задач плана или спринта, но при этом выполняются в рамках регулярных релизов.
Таким образом, можно сказать, что существует разница не столько между проектами и продуктами (хотя она и здесь есть), сколько между степенью нагрузки на используемый функционал со стороны пользователей, со стороны доступного объема данные.
Хотя, скажу вам честно: иногда срабатывает какой-то давно забытый рефлекс – смотрите, нужно двигаться дальше прямо сейчас, прямо через 10 минут! Как это работает в Туту: Поскольку наш туристический сервис сильно загружен, конечно, у нас есть понятие «блокирующая задача» — та, которую нужно сделать прямо сейчас.
Тем не менее, мы стараемся выполнять эту задачу на всех ролях, включая аналитику и качественное тестирование тестировщиком на всех необходимых стендах, если только не делаем это в более оперативном режиме.
Это позволяет нам выявлять риски и избегать будущих доработок, ненужных пробелов в коде и нарушений пользовательской логики.
В остальных случаях задаче присваивается «высший» приоритет или она попадает в багбэклог, который курируют наши дорогие тестировщики.
***
Что лучше – проекты или продукты? Слова типа «лучше» или «хуже» здесь совершенно неуместны; в этом мире информационных технологий есть место и тому, и другому.Стоит понимать особенности разных подходов, формировать правильные ожидания и рассматривать каждый проект/продукт индивидуально.
В общем, свой выбор я сделал, но совершенно его не навязываю.
У каждого свой опыт, свой бэкграунд, свои ожидания от работы.
Я говорю о продуктах, а вы решаете сами.
Теги: #системный анализ #разработка продукта #разработка продукта #проектная деятельность #продукты #аналитика #аналитика проектов #управление требованиями #управление требованиями #консалтинг #Системный анализ и проектирование #управление разработкой #agile #Карьера в ИТ-индустрии
-
Киберугрозы, Которые Ознаменуют 2011 Год
19 Oct, 24 -
Сократите Стоимость Планов Веб-Хостинга
19 Oct, 24 -
Синхронные И Асинхронные Процессы
19 Oct, 24 -
Будущее Наступает На Amf 2014
19 Oct, 24 -
Прогресс, Блин
19 Oct, 24 -
Социальные Сети И Иже С Ними.
19 Oct, 24
