Hello world

Интро пост

Да, когда-то на месте вот этого текста будет что-то полезное. А пока так.
.

Про стратегическое планирование на год

Решил поделиться тем, как мы в Spectr подошли к стратегическому планированию на год.

Стратегическая сессия.

Под нее мы выделили первые 2 рабочих дня года: работа по 10 часов с полным фокусом на решаемые задачи и никаких отвлечений на операционку. Участники: CEO (я), HRD, CTO, HoP.

1. Ставим финансовый план на год. Оставим за скобками то, как он формируется (там про стратегию на 5 лет вперед, про личные амбиции, рынок, сегменты, ограничители роста и пр.), но звучит он предельно просто: «ХХХ выручки при YYYY прибыли».

2. Освежаем в памяти бизнес-модель компании и подход к декомопозиции всей ее деятельности: Finance & Operations, HR, BizDev, Delivery. Вспоминаем, что и как влияет на получение денег и достижение годовой цели.

3. Декомпозируем годовую цель на измеримые составляющие, влияющие на ее достижение. В нашем случае с учетом всех допущений все довольно просто: продакшн-штат компании (те, кто непосредственно «деливерит»: разработчики, аналитики и пр.), объем отгрузок по направлениям, допустимый объем постоянных издержек. Раскладываем план по месяцам. Проверяем на отсутствие явных противоречий и самообманов.

4. Генерируем проблемы/идеи/задачи — это, пожалуй, самое трудоемкое, но самое важное. Тут бы без какой-то канвы и регламента выносим на обсуждение волнующие темы и … обсуждаем!

Все, что мы обсуждаем в обязательном порядке фиксируем на стене в виде стикеров. Мы для себя условились, что будем использовать только 2 цвета стикеров: желтые для конкретных задач, синие для проблем/идей/предложений (которые в свою очередь должны приводить к генерации желтых стикеров, но не всегда это возможно сделать в рамках сессии). Важно, что стикер оказывается на доске только после того, как у всех участников отсутствуют противоречия в понимании проблемы/задачи и все понимают, как проблема/задача укладывается в рамки поставленной цели.

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

5. Интуитивно объединяем все стикеры в группы (далее будем называть это «Проекты»). Повторяем упражнение до тех пор, пока количество проектов не будет меньше 10, а логика группировки не будет вызывать вопросов у всех участников процесса.

6. Распределяем сформированные проекты на стримы работы компании (те самые Fin&Ops, HR, BizDev, Delivery). Какие-то проекты НЕ будут укладываться строго в один стрим и это прекрасно! Меня, например, особенно радует, что нам удалось выделить весьма существенный набор проектов и задач, которые одновременно аффектят BizDev и HR: такая консистентность позволяет эффективно распределять усилия при реализации запланированного.

7. Проходимся по каждому стриму, смотрим на все задачи и отвечая на вопрос «чтобы что?» стараемся сформулировать ключевые цели по каждому стриму

8. Приоритизируем. Независимо друг от друга каждый участник выделяет ТОП задач, которые по его мнению должны быть реализованы в первую очередь.

По итогам стратсессии у нас есть детализированный финплан на год вперед, сформулированные цели по стримам, сгруппированные по проектам задачи.
Далее все это надо зафиксировать в доступном для людей виде.
1. Финплан — в Google-табличке.
2. Чтобы не терять фокус на целях и отслеживать прогресс — раскатываем цели в Atlas от Atlassian (пользоваться им помогает наличие иностранного юрлица).
3. Для работы и систематизации всего в рамках выделенных проектов фиксируем все в Jira Work Management. Понятный и привычный инструмент для работы с приоритетами, сроками.

Спланировали, зафиксировали. Про настройку процесса, чтобы системно выполнять запланированное напишу отдельно.

Original (31 Jan 2023): https://www.facebook.com/alekseytsykarev/posts/pfbid02CVzUS9amAVExq29AKgBQZehG58sj3Zcz8GwJhpk7D4uGR5TwVDQuoqxCJWPGePAul

2

Анонсировали Ural Digital Weekend 2023

Ссылочка на анонс: https://habr.com/ru/companies/spectr/articles/736112/

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

Будет круто 🙂

Прошлая неделя в Москве прошла очень насыщенно и завершилась церемонией продакшн-рейтингов от Тэглайн.

Spectr попал в рейтинг лучших веб-разработчиков/интеграторов России на 89 место. Еще заняли 60 место в новом рейтинге аутстаф-разработчиков.

Считаю, это хорошо, но впереди еще много работы и есть куда стремиться!

Сама церемония имеет все шансы стать легендарной, судя по количеству (и качеству!) мемов и мнений, которые уже разлетелись по интернетам 😅

Сейчас разрабатываем большую платформу для планирования и прогнозирования спроса и продаж в ритейле. Под капотом платформы более 10 микросервисов: от серверов очередей, которые координируют взаимодействие различных частей системы, до непосредственно ML-движков, которые на основе больших входящих датасетов с историей продаж строят прогнозы на будущее.

По мотивам одной из задач проекта опубликовали на Хабре хорошую статью со сравнением скорости работы двух гигантов аналитики данных в Python: Pandas и Polars.

Читать тут: https://habr.com/ru/companies/spectr/articles/738766/

7-8 июня участвуем со Spectr в Ecom Expo 2023.
Наш стенд H6.2 — давайте встречаться!

8 июня в секции «Разработка» (ЗАЛ 3 . ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ) выступаю с докладом.

Тема доклада: «Продуктовый подход в разработке: как и какие процессы и практики помогают говорить бизнесу и ИТ на одном языке».

Поделюсь нашим опытом и расскажу про то, как мы культивируем и применяем продуктовой подход в разработке для наших клиентов.
— Разница между проектным и продуктовым подходом
— Инженерные практики, которых следует придерживаться командам разработки
— CI/CD, DevOps, DevSecOps, CodeReview, релизный менеджмент
— Процессы, которые помогают ИТ держать фокус на бизнес-ценности
— Подход к организации бэклога продукта
— Подход к календарному и бюджетному планированию
— Реальные кейсы того, как продуктовый подход помогает решать задачи бизнеса

Материалы из выступления на выставке ECOM Expo 2023

Выступил на выставке ECOM Expo 2023, с докладом, на тему того, как продуктовый подход в разработке помогает решать задачи бизнеса.

Рассказал о том:
— чем отличается проектный подход в разработке от продуктового, и почему стоит делать выбор в пользу последнего, если вы хотите говорить с бизнесом на одном языке;

— что представляют из себя такие практики и процессы, как CI/CD, DevOps, DevSecOps, CodeReview, релизный менеджмент, и почему их стоит придерживаться;

— как мы в Spectr подходим к организации бэклога продукта, а также бюджетному и календарному планированию.

Делюсь материалами доклада:

Ссылка на запись доклада «Разработка и DevSecOps: существующие инструменты, процесс внедрения и сопровождения.»

Ссылка на кейс о разработке платформы, автоматизирующей взаимодействие фермеров и флористов.

Ссылка на презентацию.

Всем привет!

Это — интро.

В этом году канал станет важной частью коммуникации меня с миром. Количество событий и прикладного контента, которыми хочется делиться, стало высоким и Telegram кажется оптимальной площадкой для этого.

Несколько фактов обо мне:
• Технарь и «инфобезопасник» по образованию
• Основатель Spectr — мощного IT-аутсорс-продакшна c большой технической экспертизой и высокой инженерной культурой
• Основатель Ural Digital Weekend и #DevTalks — IT-конференции и серии митапов для разработчиков
• Основатель Florals — пока маленького, но амбициозного продукта, который совсем недавно родился в Спектре
• Партнер в Facepass — платформе для системы контроля доступа с автоматизированной системой регистрации и распознавания лиц

О чем тут будет
Включая, но не ограничиваясь:

1) О разработке цифровых продуктов. Наверное, это самое главное и необъятное. Продуктовый подход, инженерные практики, организация процессов, построение команд, планирование (календарное, ресурсное, финансовое), инженерные практики, проектирование и архитектура больших ИТ-систем, эджайл, вотерфолл и вот это вот все.

2) О разработке Florals. Florals призван оцифровать большинство процессов в цветочной отрасли. Продукт только-только зарождается и делает первый шаги, но тем интереснее, ведь его ждет впереди много всего: Customer Development, MVP, Product Market Fit, долина смерти и т. д.

3) Об организации и посещении айтишных ивентов. Да, Ural Digital Weekend и #DevTalks стали достаточно важной частью в жизни Спектра и моей — и хочется этим делиться.

4) Об управленческом и финансовом учете. В Спектре управленческий учет уже несколько лет довольно зрелый и автоматизированный. Но в условиях постоянного роста, когда большие отсрочки платежей и постоянно растущая команда, приходится часто прибегать к всевозможным финансовым инструментам (кредиты, овердрафты, факторинг…), и для сохранения контроля появляется потребность во все большем количестве всевозможных показателей, которые надо отслеживать.

Enjoy!

Оценка разработки. Декомпозиция

Будет серия постов про оценку разработки. Начать хочется с того, что любая оценка — это попытка предсказать будущее. А предсказать будущее, как известно, невозможно. И тут мы будем говорить в первую очередь о системных процессах и подходах, которые позволят работать над повышением точности оценок и их применимостью в дальнейшем процессе разработки: календарное планирование, бюджетное планирование, формирование бэклога для разработки, отслеживание прогресса, работа с ожиданиями.

Итак, про декомпозицию
Декомпозиция — разделение всего объема предстоящей разработки на небольшие задачи/фичи. Декомпозиция делается на основе входящих требований (это может быть большое и подробное ТЗ, а может быть скромный список функциональных требований — не суть).

Инкрементальный подход
Я убежден, что декомпозиция должна строиться вокруг функциональных и бизнесовых инкрементов и подразумевать, что для реализации каждого пункта будет задействована комплексная экспертиза (аналитики, frontend-разработчики, backend-разработчики, DevOps и др.). Такой подход делает разбиение полезным, понятным и обсуждаемым для широкого состава участников: и для представителей бизнеса (которые могут не понимать, что такое «фронтенд», «бэкенд» и прочие технические термины), и для технарей (которым важно понимать контекст задач и их бизнесовый смысл).

Критерии хорошей декомпозиции
В мире продуктовой разработки есть замечательная аббревиатура INVEST, — это набор критериев, которым должна соответствовать «хорошая» UserStory. Этим же критериям (с небольшими оговорками) должны соответствовать и задачи в нашей декомпозиции.

Адаптированная под оценку трактовка INVEST:
• Independent — независимость. Возможность реализовать функционал в отрыве от других фичей. На этапе активной разработки это выполнить сложно, практически невозможно, но надо стараться, и в одном из следующих постов поговорим подробнее о работе с пунктами, для которых этот критерий НЕ выполняется.
• Negotiable — обсуждаемость. Формулировка должна отражать суть, а не детали и оставлять возможность для дальнейшего обсуждения.
• Valuable — ценность для клиентов/бизнеса/стейкхолдеров.
• Estimable — оцениваемость. Понимание требований и уровень неопределенности должны позволять оценить данный функционал, и оценка должна удовлетворять критерию Small. Если критерий Estimable не выполняется, следует выходить на дополнительные обсуждения и уточнения по функционалу.
• Small — компактность. Мы для себя этот критерий уточняем следующим образом: оценка трудоемкости ни по одной из компетенций (front, back, QA…) данной фичи не должна превышать Х часов.
• Testable — проверяемость. Возможность сформулировать «критерии приемки» (Acceptance Criteria) для данного функционала через призму ценности для бизнеса и продукта, а не для команды разработки («реализована API-точка для хххх» — плохо, «пользователь системы имеет возможность скачать расходную накладную в формате PDF» — хорошо)

100%-е отражение требований
Критически важно на самых первых этапах отражать в декомпозиции 100% входящих требований. Ошибки типа «не учли это требование в оценке» — традиционно самые дорогие.
Есть очень-очень размытое и непонятное требование, с которым совсем непонятно что делать? Вынесите его в декомпозицию, пометьте как пункт на обсуждение — и работайте дальше.

Немного практики
Небольшая заметка о процессе в Spectr.
Изучать требования и делать декомпозицию — очень трудоемкий и скрупулезный процесс. Занимается этим, как правило, аналитик или даже архитектор. При наличии возможности это делает человек с опытом разработки похожих продуктов (он должен хорошо ориентироваться в предметной области или очень глубоко понимать нюансы технической реализации подобных продуктов).
В процессе первичной декомпозиции детально анализируются все требования и выделяются так называемые проблемные, из которых в том числе формируется повестка на дальнейшее обсуждение с заказчиком и с технической командой.

В будущих постах будем говорить: об оценке трудоемкости, переиспользуемости функционала, уровнях неопределенности, формировании бюджетной вилки, ролевой модели в процессе оценки (может, о чем-то еще).

Начали с командой активную подготовку к Ural Digital Weekend 2024!

В этом году конференция состоится 2-3 августа и, как обычно, соберем классных спикеров и крутых зрителей.

Уже обновили сайт — https://udwe.ru/ и собираем предварительные заявки на спикерство — https://forms.gle/MD3cbRdWd4QBpsfb9

А если написать на эту почту conf@spectr.dev можно стать партнером одной из крупнейших IT-конференций на Урале!

Все явки и пароли я дал, теперь можете посмотреть ролик прошлого года и пойти регистрироваться на UDW2024 🔥

Декомпозиция через функциональные инкременты

Что нам дает именно такой подход к декомпозиции? Вот несколько пунктов:

1) Эту декомпозицию можно As-is брать для вашего бэклога. В условной Jira это конвертируется в Story и уже в рамках каждой Story можно создавать подзадачи по отдельным людям и компетенциям. Соответственно, дашборды и отчеты построенные вокруг Story дают наглядную информацию о прогрессе реализации

2) Такую декомпозицию очень удобно использовать во всевозможных юридических документах. Мы в Spectr, например, при декомпозиции формулируем для каждого пункта критерии приемки (Acceptance Criteria) и потом при необходимости бэклог с этими критериями протаскиваем по всем документам (от договора до акта)

3) Такое очень легко и удобно обсуждать практически любым составом.
Например, фичу вида «генерация накладных в формате PDF» можно легко можно обсудить с бизнесом на предмет приоритетов, стоимости и сроков, а с разработчиками на предмет используемых библиотек и необходимости асинхронной генерации файлов — и при этом ни у кого не будет возникать критических вопросов про целевой результат фичи.

«Адекватность» и парадигмы Фридмана

У нас в базовом разделе Wiki, который видит каждый новый сотрудник, написано, что мы хотим работать в компании адекватных и профессиональных людей. «Адекватность» - довольно сложное, относительное и размытое понятие. А вот парадигмы Фридмана — одна из наиболее крутых попыток придать этому форму.

Итак, парадигмы Фридмана:

1) Проанализируй задание перед началом работы
У исполнителя должны быть все ресурсы для выполнения задачи

2) Задание должно быть выполнено на 100%
100% и по качеству и по содержанию

3) «Уперся — сообщи немедленно»
О препятствиях к 100% выполнению задания немедленно сообщи руководителю и всем заинтересованным

4) Приходи с РЕШЕНИЕМ проблемы
Предложение по решению проблемы предпочтительнее информации об ее возникновении

5) Факты и аргументация предпочтительнее мнения
Всегда подкрепляем речь доводами

6) Расширенное толкование задания не допускается
Все что не разрешено — запрещено

7) Несогласие с параметрами задания — не повод их игнорировать
Не согласен — сообщи и аргументируй. Не приняли аргументы — делай, как сказали