Финтех-проджект

Кстати, очень разделяю вот этот подход: https://t.me/ordinarypm/139.

Чего хочет пользователь, бизнес или заказчик? 🤲 В продуктовой разработке, энтерпрайзе и заказной разработке главные “боги”, которых надо ублажать проджект-менеджеру, - это пользователь, так называемый бизнес и заказчик (соответственно). Далее будем их всех для простоты называть заказчиком (в смысле “источник хотелок”). Может показаться, что задача для проджекта (в коллаборации с продактом, если он есть в компании) - это понять, чего именно хочет заказчик, и выполнить это. Но бывает так, что проджекту надо угадать, как сделать даже лучше, чем явно декларирует заказчик. То есть подумать на несколько шагов дальше и подсветить заказчику, что, скажем, реализуемый бизнес-процесс можно улучшить еще больше, тактично указать на недостатки той реализации, которую ранее определил заказчик. 🧠 А с этим даже чтение мыслей заказчика не поможет. Порой надо подумать за него и подумать лучше, чем он сам это сделал.

Привет! Есть планы сделать вокруг канала офлайн-движуху, которая будет способствовать и привлечению новых подписчиков. А пока какое-то время канал будет жить в режиме "1-2 поста в неделю". У меня по-прежнему есть в запасе интересные темы, но пока не хочу их разбазаривать😁 Не переключай канал! А вот и новый пост скоро будет, решил не заморачиваться с запланированным постом на следующую неделю, а поделиться им сразу.

Привет, пиэмчики! Был жутко занят другими делами на выходных, не было времени подготовить контент на эту неделю. Фигню писать не хочется. Не переключайтесь🤗 ❓ Пока предложу тем, кому интересно, в комментариях пообщаться про вашу вовлеченность в бизнес-процессы вашей компании (за рамками процесса разработки). У меня она очень высокая (что само по себе не есть плохо или хорошо). А у вас?

Начало и конец недели 🗓 Неделя началась. На нее есть конкретные планы. Наступила и закончилась пятница, планы выполнены. Что может быть проще? Но любой проджект и его команда могут проморгать выполнение собственных планов на неделю. Причины могут быть разные. И это даже нормально, что что-то может пойти не по плану, несмотря на все усилия. ⚠️ Тут всего лишь призываю своих собратьев-проджектов держать страничку с планами на неделю среди вкладок браузера постоянно. Мне очень помогает, так как иначе только в четверг вечером может прийти осознание, что вот эту штуку мы вообще-то собирались на этой неделе закончить. А ее даже не начинали еще. Ой. Лучше так не делать.

Friends-and-family quality? WTF? 👁 Мне давно довелось работать над проектом, который был основан на как бы коробочной разработке моего работодателя (компании). Этот “коробочный продукт” был от состояния коробки довольно далек, в итоге проект получался кривоватым и без базового функционала, характерного для таких систем (поэтому глаза представителей заказчика сильно расширялись от удивления). На каком-то этапе было принято решение заказчику предложить выбрать, какой уровень качества будет достигнут на данном этапе (скажем, на горизонте трех месяцев): прод-качество или friends-and-family-качество. Второе - это, мол, проект будет с багами, но “своим” (условным друзьям и родственникам) таким можно дать пользоваться. Уже сейчас мне это кажется плохой идеей, так как это, по сути, выбор между нормальным и хреновым. ⚰️ Проект в итоге закончил плохо (был закрыт на стороне клиента). И с тех пор я качество “friends-and-family” не предлагаю никому, даже друзьям и семье.

Подушечки для тиммейтов 🛌 Одной из обязанностей проджекта считаю создание комфорта (“подкладывание подушечек”) для тиммейтов. Нет, проджект - не нянька, и нет цели ублажить всех любой ценой и в ущерб себе и проекту. Но там, где это возможно без потери смысла и достоинства, надо делать команде хорошо. Можешь назначить созвон не на 10 утра, а на 11? Назначь на 11, чтобы не насиловать мозг коллег, у которых он нормально загружается попозже (а это частая история). Можешь не засирать разработчику голову лишней информацией и написать коротко и понятно? Сделай так. В перспективе это будут очень ценить. И не будут на тебя триггериться, когда ты все же поневоле перегрузишь команду или ее часть информацией и тупыми вопросами, не слишком продумав суть задачи. Можешь засунуть суть сообщения в первое его предложение? Сделай так. Мы все сейчас задолбанные коммуникациями, поэтому твоему тиммейту будет спокойнее увидеть суть сообщения в списке сообщений в каком-нибудь Телеграме еще до его открытия. Я часто первое сообщение начинаю словами, мол, “по такому-то вопросу”. ❤️ Можешь что-то сделать так, чтобы коллегам было комфортней? Сделай. В правильной компании и команде это станет взаимным.

Проджект и public relations Может ли проджект быть публичным лицом для пользователей? Наверное, для крупной компании с кучей ролей это “фу-фу-фу”, но в небольшой компании - вай нот, как говорится? А в заказной разработке даже в крупных компаниях проджект вполне может вещать на довольно широкую аудиторию внутри заказчика (если это большая организация). Какие есть рекомендации для проджекта с PR-вкусом? 🔎 Лучше быть граммар-наци в письменной и устной речи, а также обладать опытом и хорошими навыками изложения сложных вещей простым языком (тоже устно или письменно). 👩‍🦳 Жизненный опыт и эмоциональный интеллект (что бы это ни значило) тоже помогают, так как при любых коммуникациях (даже односторонних) важно чувствовать аудиторию и оценивать ее реакцию в реальном времени либо предугадывать реакцию в будущем. 🔬 Очень помогает изучение и знание потребностей целевой аудитории, лучше самому быть вовлеченным в использование систем в той же сфере, в которой ты и твоя команда ведете разработку (в моем финтешном случае речь идет о том, что я сам инвестор, поэтому ментально близок к миру моих пользователей, пусть даже их стиль трейдинга совсем другой). 😱 Никакой регулярный PR не проходит без факапов. Поэтому очень поможет твое умение с честью ловить какашки от пользователей, объяснять им ситуацию, делать выводы и обязательно потом им рассказывать об исправлении старой проблемы. Брехать и заговаривать уши - такое не прокатит даже один раз. Юзеры все помнят.

Финтех-эрудиция 🗜 Как уже писал не раз, финтех очень широк: в него входит вся биржевая фигня из классических финансов, всякая криптофигня, платежные системы и многое другое. У каждого финтех-проджекта своя узкая специализация. Я не уверен, что преуспел бы в каком-то разделе финтеха, в котором у меня нет опыта и знаний (например, платежных системах). Поэтому твоя финтех-эрудиция как проджекта должна быть адаптирована под ту узкую область внутри финтеха, в которой работаешь или собираешься работать. На примере биржевого финтеха (инвесттех, трейдингтех?) ниже накидаю, что я считаю финтех-эрудицией в моем случае: 💸 финансовые инструменты разных классов (акции, облигации, производные финансовые инструменты), как они работают и торгуются; 💸 как работают биржи, на которых они торгуются (какие есть сессии и особенности проведения торгов); 💸 как архитектурно устроено участие в торгах (трейдер, брокер, биржа), как это все работает на уровне серверов и протоколов (очень по верхам); 💸 как устроены расчеты на бирже (режимы торгов вроде Т+1 или Т+2, особенности выплаты дивидендов, определение дат дивидендных отсечек со стороны менеджмента компаний, как эти даты надо учитывать при желании инвестора получить или не получить дивиденд от компании); 💸 как устроен акционерный капитал с точки зрения инфраструктуры (регистратор, номинальный держатель, цепочки владения и вот это все). Этот список вряд ли исчерпывающий, но он тебе даст общий вкус того, что из себя может представлять финтех-эрудиция для узкой области внутри финтеха и финансов. 🧠 Как обрести эту самую эрудицию? В идеале - слиться с нужной тебе областью, стать инвестором или активным пользователем систем нужного тебе класса и так далее. Короче, на финтехе лучше быть женатым, чем быть для него гостевым партнером.

Задавай (тупые?) вопросы крутым технарям ❓ Для проджекта задавать вопросы (даже тупые) крутым технарям из команды - нормально. Ведь твоя задача - сделать, чтобы случилось то, что нужно проекту. Твоей IT-эрудиции должно хватать, чтобы тактично вытащить из классного специалиста в твоей команде нужное решение, давая ему вводные и задавая вопросы. Бывает такое, что подобный специалист немного зазвездился и считает (по внешним признакам) твои вопросы идиотскими, но это нормально, если не обретает токсичные формы (а если обретает, это всегда можно обсудить со спецом и внутри компании). 🧠 Но без упомянутой IT-эрудиции и хорошего знания предметной области (ненавижу слово “домен” в таком значении) - никуда.

Финтех как пирог 🥧 У всех сфер свои приколы, а финтех сложен и интересен своей многослойностью. Скажем, в инвесттехе (трейдингтехе?) слоями могут быть системы на уровне вашей компании, брокера и биржи. И на каждом из этих уровней происходит своя интересная фигня, которую ты как проджект должен понимать довольно хорошо, пусть даже верхнеуровнево. Никакая документация тебе не поможет, когда надо включить свою менеджерскую думалку и за минуты додуматься, почему что-то работает не так в вашей системе (причина может быть связана с каким-нибудь клирингом на бирже, особенностями брокера или чего-то еще). 😮 Я поэтому с трудом себя представляю в каком-нибудь ритейле, так как там наверняка тоже есть свои приколы и тонкости, для познания которых нужны годы.

Я тебя не понимать 🤷‍♂️ Бывает такое, что пользователи (особенно внутренние, если речь про энтерпрайз) тебя как проджекта и твою фичу не поняли. Можно сколько угодно ворчать об их недалекости и высказываться о них, как Задорнов об американцах, но реальность остается прежней: они тебя и фичу не поняли. Значит, надо приложить усилия и объяснить им все в виде до тупости понятной презентации или инструкции (с картинками и примерами). Спрашивать о понятности таких материалов у своих коллег из команды разработки - плохая идея, так как у вас профессиональная деформация, смотреть на фичу и продукт глазами конечного юзера у вас никогда не получится. Лучше вылови одного-двух пользователей, покажи им и попроси дать обратную связь. Пользователь - такая зверушка: если не понял что-то простое, то виноват все равно ты как проджект. Ну, либо вы с продактом виноваты, если у вас в компашке есть такая роль. 🤪 А фразу “Ну тупые!” давай оставим Задорнову.

Испыталка по плану 📊 Когда вышел на работу как проджект на одном из прошлых мест, мне был в первые недели предоставлен ИПР (индивидуальный план развития, вот!). Если по-простому - перечисление того, что от меня ожидается в течение испытательного срока. Этот документ мне очень помог, испытательный срок я успешно прошел. Впрочем, в более долгосрочной перспективе с компанией отношения не сложились, но я для себя отметил, что ИПР (или назови его так, как хочешь) - очень хорошая практика. Теперь при наборе людей в команду (речь в первую очередь о разработчиках) топлю за предоставление сотруднику такого документа. Когда такая практика только внедряется, согласование ожиданий от сотрудника внутри компании может занять недели, но оно все равно того стоит. 🍿 Новый сотрудник понимает, какие от него ожидания на испытательный срок (и плюс-минус по ходу дела понимает, проходит он испытательный срок или нет), а компания сама для себя заранее определяет критерии, по которым судить о продолжении сотрудничества.

Порядок в Джире - как заправленная утром кровать 👩‍🏫 Шитстаграмы полны утверждений, что заправлять утром кровать - уже половина успеха и порядка в жизни. Для проджекта аналог - это порядок в Джире (или ином таск-менеджере). Безусловно, есть более высокие уровни управления приоритетами и планирования (на неделю, месяц и так далее, часто об этом пишу). Но Джира - это самый низкоуровневый способ твоего взаимодействия с командой, поэтому в ней должен быть порядок: 🔨 задачи на доске должны быть с актуальным статусом; 🔨 по доске должно быть понятно, кто в команде чем занимается и будет заниматься; 🔨 должен быть реализован способ группировки тасков (например, по эпикам или релизам, смотря что вы используете); 🔨 не должно быть эпиков-контейнеров-помоек; 🔨 нужно вычесывать бэклог и закрывать ненужное и неактуальное; 🔨 и куча всего прочего, что позволит иметь в Джире самое необходимое и при этом сохранять картину понятности для любого авторизованного сотрудника компании, который залезет на доску проекта. ⏳ Как найти на это время? Делать это все регулярно, чтобы твой менеджерский “техдолг” не накапливался. Признаться, многие из названных вещей мне надо сделать в ближайшие недели самому.

С классной командой любой дурак - хороший проджект? ☺️ Чем профессиональней и сплоченней твоя команда, тем проще с ней работать. Но не все команды такие. Чем меньше твой опыт как проджекта, тем труднее тебе будет работать с командой с неидеальностями. Бывает, что это даже не вопрос твоего профессионализма как менеджера проекта. Возможно, что вы с командой просто не подходите друг другу (и в целом сама компания не подходит тебе). Наверное, есть какие-то гениальные проджекты, которые могут работать прекрасно в любой компании и с любой командой, но лично я к таким не отношусь. У меня было, что мэтч с командой и компанией случился, но бывало, что и не случился. 🤘 Самый кайф - это когда у тебя уже есть опыт и тебе еще и достается офигенная команда, которая максимально автономная, но ты при этом приносишь пользу компании, команде и процессам, как дирижер приносит пользу своему оркестру.

“Darkest Hour” для проджекта 🌃 Есть такая книга (и фильм) про Черчилля - “Darkest Hour” (“Темные времена” в русской версии). У каждого проджекта (в заказной разработке или продукте) с какой-то периодичностью случается такой “темный период”: 🙀 заказчик взбесился, нафантазировал новые фичи и хочет выполнения больших работ за неделю или даже дни; 🙀 заказчик или третья сторона (подрядчик по какой-нибудь 1С) жевали сопли 2 месяца по изменениям на своей стороне, а теперь выполнили их - и им приспичило довести задуманное до конца до вчера; 🙀 из-за изменений во внешней среде (пример в финтехе: биржа изменила особенности торгов; либо произошли регуляторные изменения) надо срочно дорабатывать вашу систему; 🙀 и прочие обстоятельства, когда по зависящим и не зависящим от проджекта причинам ему и команде надо работать на износ. Как предотвращать такие ситуации - отдельный разговор. Но они в любом случае случаются. Такие периоды надо пережить с максимальной отдачей и заботой о проекте и команде, в последнюю очередь - с заботой о себе. Насколько убиваться проджекту, зависит от обстоятельств и твоей преданности проекту и / или продукту. Убиваться - не самоцель. Надо этот период пережить с умом, совершать только выверенные действия, которые минимизируют изматывание команды и максимально приблизят вас к тому, чего требуют заказчик, твои боссы и ситуация. 🌅 Достойно пережитые “темные времена” - хороший вклад в твою проджектскую репутационную копилку. Может, потом книгу про это напишешь или заведешь Телеграм-канал, как я.

Проджект не держит дела в голове. 🧠 Может, среди нас есть гении, но я к ним не отношусь. При работе даже на проекте не самого большого масштаба количество одновременно прорабатываемых и разрабатываемых блоков (инициатив, эпиков, называй как хочешь) может легко превышать 10, а внутри каждого из них может быть куча разных мелочей со своими сроками выполнения, и все это проджект должен держать в голове. Но держать в голове - плохая идея. Для планов разных временных горизонтов (неделя, месяц, квартал, год) хорошо подходит конфлюенс. А для совсем краткосрочных вещей мне помогает обычный бумажный блокнот, в котором пишу то, что лично мне надо не забыть в ближайшие дни. По мере выполнения пункты из такого блокнота вычеркиваются ручкой. Такой вот олдскульный подход.

Проджект-всезнайка? 🛠 Нужно ли проджекту в финтехе или любой другой сфере до последнего винтика знать проект или продукт, включая всякие там админки, конфигурации и пр.? Считаю, что нет. Вполне нормально в целом понимать, что там на уровне пользователя или администратора делается в том или ином блоке. Если у разработчиков, аналитиков и QA команды есть экспертиза, то вполне нормально ей пользоваться, погружаясь на более низкий уровень, когда это касается проработки конкретной фичи или изменения в рамках общего высокоуровневого роудмапа.

Почему Федя дорого обходится продукту? 🏹 У меня есть друг Федя, он предпочитает не обновлять приложения и очень огорчается, когда старая версия перестает поддерживаться. Мол, опять эти из такой-то компании что-то новое напридумывали, зачем это нужно, если меня и старое устраивало (а оно теперь не работает)? Ответ прост. Поддерживать старые версии приложения - очень дорого для продуктовой компании. И не развивать продукт нельзя, он не может стоять на месте: будет много версий, на долгосроке в приложении приживется и останется только то, что действительно нужно пользователям. Но каждая новая фича наверняка кому-то не понравится: если не Феде, так Васе или Алине. Мне довелось рулить очень ресурсоемкой мегафичей в одном крупном финтех-продукте. У нас был очень долгоиграющий эпик (группа задач) под названием “legacy API”. Целью было обеспечить работоспособность API приложения для устройств с очень устаревшими версиями приложения. Этот эпик закрывался не один месяц командой из нескольких разработчиков, что не могло не отвлекать от по-настоящему нужных пользователям фич. В этом был смысл, так как платящих пользователей среди этих любителей старья было достаточно. Но все равно меня не могла не посещать мысль: может, к черту этих старьевщиков, пусть меняют свои старые девайсы и приложения, раз им так нужен наш продукт? 💸 Так что Федя как пользователь очень дорого обходится любому продукту.

Молчание проджекта - золото. 🤐 Умение общаться с командой и всеми стейкхолдерами в компании и вовне - мастхэв для проджекта. Но убежден, что его молчание во многих ситуациях и процессах - золото. С соработниками можно и нужно сохранять дружелюбность, заполнять паузы, облегчать общение. 🙊 Но чрезмерно болтливый менеджер проекта - источник проблем. Есть оправданный small talk, в остальном же каждое слово и интонация проджекта должны бить в цель, иначе можно, образно говоря, не донести ведро до места назначения, не расплескав его.