Представляю вам свой новый продукт - себя!
История, с которой всё началось
Несколько лет назад, когда я работал в аутстафф компании, нам поступил интересный запрос от одного заказчика. Его команда год работала над приложением, он потратил миллионы рублей, а работа всё никак не могла закончиться. Была куча багов, дедлайны не выполнялись, и он хотел понять: что происходит, и как это исправить?
Так родилась идея: мы берём с заказчика небольшую сумму (намного меньше, чем найм техлида), и я делаю аудит работы его команды и кодовой базы, чтобы как третье лицо, без предрассудков, проанализировать, почему работа не ладится.
Что я обнаружил
Я потратил несколько десятков часов, тщательно анализируя кодовую базу и историю изменений, приходя на созвоны и разговаривая со всеми членами команды тет-а-тет.
Во-первых, на том проекте была архитектурная проблема. Человек, который стартовал проект, думал, что это демо, и даже не был Android-разработчиком. Это был iOS’ер, поэтому он не использовал Compose, не было никакой архитектуры, не настроил DI, не модуляризовал приложение, не знал ничего о том, как работать с Gradle, и сделал всё так, чтобы код этого приложения был наиболее похож на Swift.
Разработчики, которые пришли после этого, не знали, что это долгосрочный проект (первый показал демо, новым отдали код с демки). Они продолжали пользоваться теми же паттернами, не привнося ничего нового, и просто писали код так, как он был заложен изначально, думая, что так и было задумано. Более того, разработчик, который это всё начал, уже ушёл, а замену ему не нашли. Из-за этого кодовая база разрослась в кучу еле-еле работающего спагетти-кода на устаревшем стеке. В команде фактически не было архитектора, некому было принимать решения.
Решение
После того, как я провёл аудит, я сделал заказчику документ с планом по решению проблем с приоритетами для бизнеса, который он может отдать разработчикам. Там были разные вещи: назначить техлида, добавить тех. этап в продуктовый дизайн, compose, настроить DI, архитектуру, как разбить на модули.
Всё это я оформил на двух языках - разработчиков и бизнеса. Это был мой первый опыт работы продуктовым инженером - тем человеком, который является мостом между командой разработки и бизнесом, который переводит язык разработчиков, например, “Gradle конфигурация долгая”, или “на вьюхах DSL стрёмный с iOS” в язык бизнеса:
Разработчики тратят 5k$ твоих денег в месяц на ожидание, пока загрузится код, нужный им для работы. Вот как исправить - займёт 16 часов, окупится через 30 дней.
Я оцениваю итоговую стоимость документа в сотни тысяч рублей: он помог заказчику принять ключевые решения и сэкономить бюджет, сжал весь мой опыт до 10 страниц, и содержал инструкции от А до Я как ускорить разработку в ~2-3 раза.
Почему это важно в эпоху ИИ
Совсем недавно, после ухода с последней работы, я провёл больше недели в раздумьях о том, что же мне делать в эпоху ИИ, когда код можно писать намного быстрее и дешевле. Моя главная ценность больше не заключается в том, что я умею писать код, даже если код, который я пишу, идеальный (а он - нет).
Но за 600 часов работы с ИИ я понял, в чём у ИИ будут слабые места ещё многие годы: системный дизайн, архитектура и коммуникация. Владелец бизнеса не может дать ИИ принимать решения без технического контекста, который нужен для понимания бизнеса целиком, а разработчик не может дать хорошо ИИ задачу без понимания продуктовой стратегии. Я уже видел это на своей прошлой работе, где у нас был огромный разрыв между QA, разработчиками и продуктовой командой, потому что все три разговаривали на разных языках, и не было конкретного человека, который бы мог организовать коммуникацию и связать бизнес-требования и технические детали.
Так ко мне и пришла идея о том, что я наиболее полезен могу быть в эпоху ИИ через мою экспертизу в архитектуре приложений, в системном дизайне, и благодаря продуктовому уклону, так как я сам уже сделал несколько продуктов от А до Я.
Моя Ikigai
Работа подобным экспертом и консультантом попадает в центр моей диаграммы Ikigai:
Я всё своё детство копался сначала с лего, потом перепрошивая по сто раз свой телефон и оптимизируя каждую мелочь в нём, потом кастомизируя дистрибутив Linux по 200 часов (я на арче кста), и до сих пор трачу выходные, вылизывая свой собственный архитектурный фреймворк по ночам. Подобная работа в архитектуре, анализе и дизайне сложных систем была бы мечтой для меня.
Я слышал больше всего позитивных отзывов и похвалы в своей жизни именно о своей экспертизе не только в разработке, но ещё и в том, как я свои знания доношу другим людям. Без обучения и коммуникации в оптимизации работы команды не обойтись. Поэтому здесь как нельзя кстати придётся мой опыт преподавателя в университете и автора программы стажировки.
Призыв к действию
Этот пост - призыв к действию.
Если вы разработчик, и вам хотелось бы, чтобы я пришёл, помог вам разобраться с проблемами на работе, сделать вашу жизнь как разработчика лучше, научить вас новым технологиям или работе с ИИ, и сэкономить деньги вашему бизнесу, я прошу вас поделиться ссылкой на мой обновленный сайт nek12.dev с вашим руководством или тимлидом.
Если вы владелец бизнеса или CTO, я предлагаю вам выйти на бесплатный 20-минутный созвон, и я скажу вам три самых больших рычага для вашего бизнеса.