В психологическом тупике или легко ли войти в ИТ?
Проработав в продажах более 25 лет в финансовой сфере, я осознал необходимость нового витка в карьере. Накопленная усталость работы со стандартными продуктами, которые сделал кто-то другой, отсутствие развития и «стеклянный потолок» регионального менеджера стимулировали искать разные варианты профессиональной траектории.
Одним из популярных направлений казалась ИТ-отрасль, ведь слоган «войти в ИТ» стал уже культовым. Многочисленные онлайн-школы и курсы продолжают обещать смену профессии через «практика, практика, практика, а затем не опоздайте на собеседование».
Однако всё оказалось гораздо сложнее, так как фактически происходило обесценивание накопленных отраслевых знаний, и ты оказывался в одной шеренге с начинающими молодыми джунами, которые так стремились стать удалёнными высокооплачиваемыми аналитиками, тестировщиками и проджектами. Им гораздо легче давалось большинство инструментов в силу ещё не перегруженного жизненным опытом биологического диска памяти.
Поэтому, несмотря на оконченные курсы анализа данных и управления ИТ-проектами это не дало желаемых результатов и поставленные цели не были достигнуты. В итоге вместо развития карьеры я, наоборот, упирался в её сужение при входе в новую специальность с серьёзной конкуренцией среди начинающих, в которой было сложно выделить свои преимущества.
Свет в конце тоннеля или как я познакомился с проджект-раннером
Я не сдавался и продолжал поиск вариантов. А когда ищешь, то обязательно найдёшь. В прибрежном городе своего региона я познакомился с автором книги «Метод параноика» - Вадимом Митякиным. В ней он систематизировал свой опыт и опыт своих коллег за последние 30 лет работы, чтобы предложить новый подход к созданию цифровых продуктов. Концепция книги мне сразу откликнулась. Вадим назвал её «Метод параноика» по аналогии с культовой книгой Эндрю Гроува «Выживают только параноики. Как использовать кризисные периоды, с которыми сталкивается любая компания».
Прогуливаясь у моря с Вадимом, я обсуждал с ним наболевшие вопросы, тенденции развития ИТ-отрасли, методологию проектирования и реализации цифровых продуктов. В итоге через некоторое время, у меня сложилось понимание куда стоит двигаться. Между бизнесом и ИТ - специалистами часто возникает коммуникационный барьер: они используют разный профессиональный язык и оперируют различными категориями мышления. Когда что-то не получается, стороны просто перекладывают ответственность друг на друга, ведь каждый смотрит на процессы со своей стороны и не имеет большого желания «влезть в шкуру» оппонента. Люди, которые могут взглянуть на задачу с разных сторон и уровней абстракции, - большая редкость. Вадим назвал такого специалиста, который выступает для бизнеса проводником в мир технологий, а для специалистов переводчиком с языка бизнеса – проджект-раннером.
Мне очень откликнулась идея проджект-раннера, а описанные принципы, совместно с накопленным опытом и домученным ИТ-образованием (изучение python и sql я запомню надолго) позволили собрать целостную картину направления, в котором появилось желание развиваться. Находиться на острие предметной области бизнеса и ИТ, так как любой современный продукт имеет две стороны медали: бизнес-продукт и технологический продукт. За бизнес-продукт отвечает линия бизнеса, а за технологический продукт ИТ-команда.
Шанс! Он выпадает только раз!
Как раз появился шанс на работе. Моё увлечение методологией и активная жизненная позиция способствовали выходу на новую работу в своей отрасли андеррайтером (это сотрудник, уполномоченный на согласование условий продукта и оценку рисков). Как раз на этой позиции меня ждал новый вызов. Предстояло сделать следующее:
Перенести продукты с одной технологической платформы продаж на другую. При этом с монолита мы переходили на микросервисную архитектуру.
Необходимо было не просто перенести текущие продукты, но модернизировать их с учётом актуальных продуктов лидеров отрасли, т.е. сделать их «как в лучших домах».
Сплотить участников команд, так как при проектировании и реализации сложных финансовых продуктов в разработке участвуют несколько команд из разных подразделений (фронт, бэк, ядро, учётные системы) и предстояло очень много синхронизаций.
Я вошел в состав одной из ИТ-команд в качестве представителя линии бизнеса. Регулярное участие во всех мероприятиях – ежедневках, планировании спринтов и ретроспективах позволило глубоко погрузиться в особенности разработки финансовых продуктов и сформировать продуктивные отношения с коллегами.
Метод «параноика»
Концепцию проджект-раннера я адаптировал для своей ситуации. В этом помогло глубокое знание предметной области, процессов управления продуктом и структуры больших финансовых компаний из серии Too Big to Fail. Концепция включает в себя набор принципов, которые я использую в своей работе:
Базовый сквозной принцип. Контроль неопределённости.
Каждое решение в проекте сводилось к уменьшению степени неопределённости. Применение описанных в книге инструментов — «воронки неопределённости» и «проектных тисков» — обеспечивало эффективное решение задачи. На все возникающие вопросы – я спрашивал себя: увеличивает это или уменьшает неопределённость. Понимание принципа позволяла эффективнее достигать целей.
Принцип вовлечённости бизнеса
Создание цифрового финансового продукта напоминает решение уравнения с множеством переменных. Приходится работать на всех уровнях: бизнес-уровне, функциональном, интерфейсном, техническом и организационном. При реализации я общался с большим количеством людей от аналитиков разных подразделений до дизайнера и корректора документов. Часто видео конференции были практически весь рабочий день, а документами и анализом я занимался в выходные.
Во время работы над проектом каждый уровень постоянно уточняется и детализируется, поэтому без представителя бизнеса его реализация крайне затруднена. Тем более, я чётко понимал, что после вывода продуктов в продажу, буду отвечать за их бизнес-результат. Стоит отметить, что в отличии ИТ-специалистов, отвечающих за конкретную область, мне приходится постоянно держать все уровни в голове. С чем-то помогали более опытные коллеги, до каких-то вещей приходилось доходить самому. При этом я часто пояснял коллегам физический смысл работы продукта, что значительно помогало в его реализации и приоритизации задач и внимательно слушал обратную связь от самих разработчиков, аналитиков и тестировщиков. В итоге мы дошли до того, что, разрабатывая динамические маски договоров, я начал понимать как знаки препинания или разбиение текста на абзацы могут усложнить либо наоборот облегчить работу коллег. С аналитиками и разработчиками вместе мы описывали сложные формулы расчётов в продукте, а с тестировщиками составляли тест-кейсы.
Принцип проектирования
Одной из самых сложных задач была разработка проектной документации продуктов, которую мы делали вместе с аналитиками. Сложность заключалась в том, что сначала нужно было разработать понятную для всех форму брифа продукта на общем ресурсе, разобрать текущий продукт на атомы, существенно переработать его с учётом продуктов конкурентов и затем собрать уже в формате итоговой проектной документации. При этом как часто бывает, по текущим продуктам какой-то документации вообще не было. По личному опыту знаю, как ошибки или неточности проектирования со стороны бизнеса, а затем их переделка, влияет как на стоимость и время разработки, так и на недовольство членов команды. Ошибки и недочёты регулярно становились предметом обсуждения.
Принцип гибких команд
Этот принцип определяет правила формирования и управления командами. Мой опыт проектирования и реализации продуктов подсказывает, что сплочённость и погружённость членов команды в конкретную предметную область существенно облегчает работу, непосредственно влияет на скорость и стоимость разработки. И наоборот, частая смена сотрудников, их переброска в другие проекты из-за нехватки ресурсов усложняет задачу и демотивирует людей. Для нашей работы критично важна именно стабильность и мотивированность, а не часто сменяемый звёздный состав. Чтобы полностью погрузить нового сотрудника в сложные проекты и структуру работы большой финансовой компании нужно от 6 месяцев до 1 года. Гибкость нужна для того, чтобы несколько команд могли работать вместе, согласовывать действия и эффективно общаться.
Принцип продюсирования
Как уже сказано выше, этот принцип по задумке автора вводит особую проектную роль – проджект-раннера и продюсерскую модель работы (по аналогии с шоураннером в киноиндустрии). Да, как в книге, у нас такое пока не реализовано, но основное - глубокая вовлечённость и личная ответственность за результат имеет место. Могу предположить, что формат работы, которую я сейчас веду, это не проджект и не продакт в классическом виде. Скорее больше похоже на микс из мультидисциплинарности, необходимости интеграции широкого спектра вопросов от разработки концепции до системности и непрерывности управления жизненным циклом финансовых продуктов.
Принцип сериала
Создание цифровых продуктов напоминает сьёмку сериала с множеством эпизодов. Каждая новая версия, с одной стороны, должна развивать систему, а с другой сохранять её целостность. Мы применяем данный принцип, перенося и развивая всю линейку продуктов. Обкатав схему переноса одного продукта, делаем выводы и совершенствуем процессы переноса следующего. И так продукт за продуктом. Хотя, иногда делая очередной продукт, мы обнаруживали ошибки, допущенные в уже реализованном. Приходится заводить новые задачи по доработке, краснеть, извиняться и делать выводы.
А что в итоге?
В итоге мы реализовали перенос большей части продуктов и запустили обновлённую линейку в продажи. На очередном демо команда так подвела итоги участия представителя бизнеса и применение данных принципов:
Значительно ускорился бизнес-анализ
Сократилось количество ошибок при разработке продуктов
Оптимизировались процессы за счёт глубокого погружения представителя бизнеса в разработку (улучшилась качество проработки узких мест благодаря решениям андеррайтера)
Все вопросы решаются в лайв-режиме
Установлена прямая коммуникация: разработчик-андеррайтер
Заключение
Сейчас в своей работе я часто возвращаюсь к книге «Метод параноика» и нахожу в ней новые идеи, которые адаптирую и совершенствую. Развитие происходит только через действие. Причём наиболее эффективным на мой взгляд оказалось действие на стыке дисциплин в своей отрасли. А подсвеченный рекламными сообщениями путь входа в ИТ не очень рабочим. Возможно, моя история будет полезна для тех сотрудников компаний, которые упёрлись в потолок и ищут не только пути развития своей карьеры, но и новые смыслы. Ведь, согласитесь, приятно, когда техлид говорит: «Хорошо, что ты у нас есть».
