Советы самому себе

Добродетели для роста в ИТ-карьере

Mon, 17 Mar 2025 19:45:39 +0400

В выходные выступал в ИТ-лицее перед родителями и педагогами, рассказывал что помогает добиваться успеха в карьере на примере опыта команды Натнэт.

Посчитал, что за 16 лет через компанию прошло больше 320 человек, 60% команды начинали работать будучи студентами.

Многие из них остались в отрасли и показали результат — открыли свое дело, перешли в продукты (кто-то в небольших влияет на бизнес-показатели, а кто-то трудится в больших продуктах), занимают руководящие должности.

Ключевой тезис:

Технологии приходят и уходят, остаются люди, которым доверяют.

Выводы, кратко:

Одних развитых хардскилов для быстрого роста недостаточно
Решают личностные качества, которые надо развивать:
- Ориентация на развитие
- Самоанализ, логическое и критическое мышление
- Ориентация на результат и ответственность
- Работа в команде
- Инициативность и настойчивость
Важно любить, что делаешь → тогда будет рост
Личностные качества развиваются с рождения, но если очень хочется — можно начинать в любое время:
- Составлять план развития: осьминожка навыков, цели и их трекинг
- Постоянно просить обратную связь: делать это правильно
- Развивать самостоятельность и настойчивость: даю примеры как
- Смотреть как работают другие → заземляться в рынок

Презентация

Полная версия «Какие люди добиваются успеха в ИТ» в PDF.

Симулякр итогов с Ural Digital Weekend 2023

Mon, 14 Aug 2023 18:29:50 +0400

С 3 по 5 августа провел с коллегами в Перми на Ural Digital Weekend 2023. Ничего не ждал и был удивлен уровнем организации, фестивальной атмосферой и кучей топов из заказной разработки.

Чтобы не пропало, делюсь заметками с поездки:

Общее

Важность препати на профильных конференциях была мною сильно недооценена
Критически важно выходить с уровня бизнес-заказчика на уровень топ-менеджеров и владельцев, чтобы не терять контакт с клиентом из-за смены менеджмента. И в дополнение — регулярно собирать обратную связь от топ-менеджеров и владельцев, чтобы реально оценивать ценность которую вы доносите до бизнеса клиента
Отчеты для T&M-контрактов можно делать на BI — реалтайм-обновление и полная прозрачность
Первый месяц можно продавать по постоплате, чтобы снизить риски клиента (интересная мысль, но не сталкивался с таким возражением на пресейле)
Мало экспертизы на этапе продажи не бывает

Разработка своих продуктов

Значимые тренды рынка энтерпрайз-систем
- Освободилась существенная доля рынка из-за ухода зарубежных продуктов (нужны замены ушедших систем)
- Технические тренды: микросервисы, lowcode/nocode стек, RPA
- Господдержка импортозамещения
- Самописные внутренние разработки крупных игроков
- Риски потери кадров (релокация, конкуренция за ИТ-кадры)
- Новые продукты крупных российских интеграторов
- Монетизация собственных решений
Не получится сделать продукт из готового решения, которое разрабатывалось под конкретного заказчика. Но для поиска «болей» рынка и формирования плана по развитию такого продукта можно использовать привычный Jobs To Be Done и мало известный Pain Chain
Почему здорово делать продукт с клиентом:
- Глубочаяшая отраслевая экспертиза
- Выходы на всех ЛПР в отрасли
Почему клиенту здорово делать продукт с агентством:
- Экспертиза в разработке
- Умение продавать ИТ-решения
- Понимание того что такое клиентский сервис в ИТ (продукт может требовать внедрения)
- Гибкость (агентство всегда меньше и быстрее)
Обратная сторона продуктовой разработки
- Очень сложно найти первых клиентов, свою кор-аудиторию
- Высасывает ресурсы (деньги и людей)
- Размывается фокус внимания
- Расходы сложнее планировать
- Расхолаживает команду, после клиентских проектов
- Сложно контролировать команду, если делаешь продукт бенчем (так не надо делать)
Рекомендации по организации запуска продукта
- Жестко фиксировать этапы и бюджеты на свои продукты. Будьте готовы потерять эти деньги
- Учитывайте все затраты на разработку, в том числе косвенные затраты и упущенную прбыль
- Подумайте как будете использовать продукт, если он не взлетит
- Выделенная команда и четкие роли в ней
- Выделен ответственный за продукт (визионер) с четкими, прописанными KPI. Найдите человека, который будет думать о продукте всё время (не пол дня).
- Ответственный за продукт — не просто продакт, это драйвер процесса. Зачастую это должен быть СЕО\СОО\партнер — очень замотивированный предстаитель отдельного бизнес-юнита. Поэтому начать стоит с драйвера, тогда будет все чуть проще.
- Относитетсь к продукту как к заказчику своего агентства.
- Четко поставлены цели: smart, harvest, mece
- Продукт и основной бизнес не соперничают друг с другом
- 10 раз убедиться что за продуктом стоит реальная боль, а не фантазии (даже если это фантазии самых главных людей в компании). Убедитесь, что сфера продукта близка вашему агентству
- Проработайте бизнес-модель, не смешивайте ее с агентской моделю
- Рассказывайте о продукте и том, как его делаете
С какими клиентами будет сложно прийти к продуктовой разработке:
- Если нет процессов продуктовой разработки или текущее понимание больше на стороне заказчика
- Работаем по спринтам, но не видим смысла в бизнес-аналитике или системном аналитике. Заказчик не подпускает подрядчика к внутренней кухне, работаем в режиме черного ящика (ВА, привет)
- Продукт не совсем продукт, не приносит ценности бизнесу, обречен на правал
С какими клиентами возможно прийти к модели продуктовой разработки:
- Если у заказчика есть фреймворк продуктовой разработки и он внедрен хотя бы частично
- Заказчик понимает ценность продукта и имеет план развития
- Заказчик умеет пользоваться всеми инструментами аутсорса
Если продукт не развивается — не увеличивается бюджет на его развитие.
Как устранить раскол между ИТ и бизнесом — путь к успеху агентства:
- Не пытаться занимать только одну из сторон (важно всё и сразу: делать важные для продукта задачи, по правильному процессу и быстро, чтобы бизнес возвращать инвестиции)
- Объяснять бизнесу почему в долгосрочной перспективе нужно учиться слыть ИТ: архитекторов, лидов и СТО
- Снабдить ИТ бизнесовой фактурой для продажи своих позиций, сделать ИТ-метрики управляемыми
- Помочь ИТ лучше отвечать требованиям бизнеса, а бизнесу предоставить для ИТ требования в понятном виде
Фреймворк продуктовой разработки, который должен настраиваться и постоянно адаптироваться, чтобы минимизировать ТТМ:

Этап	Бизнес-инициатива или гипотеза	Оценка и приоритизация	Бизнес-анализ	Системный анализ	Разработка
Кто	Кто угодно: стейкхолдеры, СЕО, владелец продукта	Лид разработки, БА, Владелец продукта	БА, Владелец продукта, РП, ITBP, стейкхолдеры	Лид разработки, Владелец продукта, РП	Лид разработки, РП
С каким результатом	Сделаем что-то что сделает продукт более ценным для потребителей с целью увеличения бизнеса	Понимаем сложность и сроки в попугаях, понимаем профит, приоритизируем	Декомпозированные бизнес-требования, CJM, EJM, описанный бизнес-процесс. Дизайн, UX, ограничения	Техническое решение, декомпозиция задач, в том числе по системам, беклог готовых, оцененных и готовых к разработке задач	Задачи в рамках изначальных БТ, готовые к релизам (или UAT\AB\E2E) во всех системах
Пример	Если мы автоматизируем процесс оформления заказа — улучшим SLA дял клиентов, сэкономим Х рублей на операционных затратах	Клиенты смогут оформить заказ в любое время суток, бизнес сэкономит и высвободит операционного ресурса на 20 млн в год	Осознание, что требуется доработка в 5 бэкенд-системах, юридические и финансовые аспекты улажены, готов дизайн, описан процесс, посчитан P&L	Эпик или сторя, в который собраны все задачи с оценками. Осталось только положить в спринты по системам согласно приоритетам	Команда разработки готова провести демо нового функционала бизнесу и готова к отгрузке на бой

Команда

Для создания эффективной команды нужны единая цель, где каждый преследует цель компании и взаимодействует друг с другом
Почему командная работа решает на уровне задач Complex (об этом чуть ниже):
- Делает возможным решение задач, что не под силу одному человеку
- Является гарантией, что будут учитываться интересы всех сторон
- Понижается риск принятия ошибочных решений
- Помогает бороться с производственной слепотой
Чтобы у команды появилась сопричастность к происходящему, сопереживание проблемам, поддержка и продвижение изменений, повышения доверия и генерация идей — она должна быть плотно интегрирована в то, что у компании происходит и наоборот. Для этого существует точки для сбора и передачи информации, дальше об этом
Какие могут быть точки для сбора информации:
- 1-2-1 RM
- 1-2-1 HR
- 360
- Командные встречи
- Чаты
- Эскалации
- Perfomance review
- Проектные ретро
- Неофициальные встречи
А какие системы передачи информации:
- Планерки топов (еженедельно)
- Планерки менеджмента (каждые 2 недели)
- Планерки отделов (каждые 2 недели)
- Общая встреча компании (квартальные, годовая)
- Мероприятия по изменениям
- Личные встречи
- Дополнительные: почтовые рассылки (nda\not nda), телеграмм-канал, общий чат в телеге, сессии Q&A.
О чем компания может делиться с менеджментом:
- Всё и максимально открыто
- Продавать прототипы изменений и собирать обратную связь
- Просить задавать неудобные вопросы
- Рассказывать о возможностях и искать лидеров
- Показывать проблемы и искать совместные решения
О чем компании стоит делиться со всеми:
- Об изменениях (которые уже поддерживает менеджмент)
- Проблемы — с решениями от менеджмента
- Возможности — с запросом на участие
- Выручку, прибыль — в процентах

Проекты

Каскадная модель производства драматически снижает вероятность успеха проекта
Cynefin framework https://ru.wikipedia.org/wiki/Cynefin_framework — как концептуальная основа для принятия решений:
- Obvious. Применяйте «Best Practice». Задачи ясны, решения очевидны, следуйте установленным процедурам.
- Complicated. Применяйте «Good Practice» или экспертные мнения. Возможно несколько правильных решений
- Complex. Проведите эксперименты и используйте «Emergent Practice». Тут нет очевидных решений, выясните правильный подход через пробу и ошибку.
- Chaotic. Действуйте сразу для стабилизации ситуации, затем изучайте и отвечайте на изменения. Нужно немедленно действовать.
В разработке нетиповых решений часто приходится решать задачи уровня Complicated и Complex, поэтому взвешивайте решения. Complicated — это граница проектной деятельности, начиная с Complex — это задачи в зоне эмпирической деятельности, а значит мы не можем говорить о каскадной модели и вотерфоле для таких решений. Это всё Симулякр плана, как выразился Глеб Михеев :-)
Иногда стоит принять, что ты не можешь определить точные требования и вместо требований определить цель и ключевые результаты (это, кстати, пересекается с тем что говорят ребята из Бюро про ФФФ). Это зона неопределенности, её невозможно спланировать. Это зона командной работы.
Что пропагандирует аджайл:
- Люди и взаимодействие важнее процессов и инструментов
- Работающий продукт важнее исчерпывающей документации
- Сотрудничество с заказчиком важнее согласования условий контракта
- Готовность к изменениям важнее следования первоначальному плану
В аджайле развитие. Аджайт создает продукт, ватерфолл его воспроизводит
Немного о концепции Run-Change-Disrupt

На кого подписался после конфы

https://t.me/panfilovonline Пишет про запуск digital-проектов и IT-инструменты для бизнеса
https://t.me/rukovozhu Виктор Рындин: CEO @Wemakefab & @Dprofileru
https://t.me/tired_glebmikheev Глеб Михеев, просто поток сознания на стыке менеджмента и ИТ, я влюбился
@dpletnev. Дима Плетнев. Но он ничего в паблик почему-то не пишет, приходится писать в личку
https://t.me/successfulproduct Сергей Пращенко, про продакт дискавери вообще и в энтерпрайзе в частности (самый недооцененный доклад, потому что было жутко интересно, но все выдохлись)

Ну и посмотрите запись трансляции, очень много достойных лекций:

Нетворкинг на GASTREET 2023

Mon, 19 Jun 2023 10:48:39 +0400

С 5 по 7 июня провел на восьмом GASTREET в Красной поляне. Делюсь заметками по разработке для ресторанов и опытом нетворкинга.

Заказная разработка для ресторанного бизнеса

Ресторанный бизнес — это много низких чеков, клиенты голосуют рублем каждый день. Монументальные и дорогие решения могут позволить себе только сети и крупный ресторанный бизнес, которые точно знают как это окупится.

У большинства очень схожие проблемы: не считают маркетинг, нет метрик для принятия быстрых решений (или они не на поверхности), автоматизация из коробки закрывает не все потребности, регулярные технические проблемы с iiko или r-keeper.

Большинство автоматизируют процессы как видят сами, не опираясь на опыт отрасли; учатся на своих ошибках. Из-за этого даже единичные рестораны нуждаются в уникальных ИТ-решениях или уникальных связках разных ИТ-продуктов.

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

Идеально развивать клиентов в нише в двух направлениях:

Разрабатывать и внедрять нишевые продукты.
Тиражировать опыт в нише, предлагая индивидульные решения с переиспользованием какой-то части продуктов и экспертизы команды.

Специализация окупается. Вот, например, Lemma — интегратор в хореке, работает со средней ставкой около 5000 Р. Это примерно в 2 раза выше средней ставки в заказной разработке.

Перестаньте делать привычным образом

Thu, 19 Jan 2023 00:31:22 +0400

Со временем любой глаз замыливается, подход в принятии решений встаёт на рельсы и становится рафинированным.

Чтобы этого не происходило, нужно не бояться выдергивать себя из привычной жизни. Менять темп, изменять привычкам, разминать мозги:

ездил на работу на такси, пройдись пешком
делал глубокий анализ прежде чем принять решение, примите решение сейчас — минута, время пошло
обычно делаешь задачи сам, делегируй
обращаешься за опытом к книгам и ютубу, сходи к коучу

Вагон наблюдений возможность увидеть какими правильными привычками живёшь.