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

Ключевые показатели бизнеса аутсорс-компании

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

Что это за показатели, если мы говорим про IT-компанию в заказной разработке? В результате многолетней работы, экспериментов, внедренных процессов и инструментов могу сказать, что почти всегда все сводится к среднему рейту и Realization Rate.

Средний рейт
Среднее значение рейта, по которому вы продаете клиентам своих производственных людей (программисты, аналитики, QA, менеджеры и т.д.)

Realization Rate
В общем случае, это отношение фактически проданных часов (Billable Hours) к общему количеству возможных часов (Total Hours).
Realization Rate = Billable Hours / Total Hours.
Т.е. если у вас в штате только один разработчик и за месяц (в котором 160 рабочих часов) вы выставили клиентам 80 часов его работы, а остальные часы он занимался какими-то внутренними активностями — Realization Rate составит 50%.
Часто этот же показатель называют «Billability»

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

А вы дружите с джунами? Обсудим на «Стачке»!

С 2019 года мы перепробовали разные способы взаимодействия и работы с джунами: делали образовательные курсы, стажировки, митапы и онлайн-курсы — мы все это время старались построить трек для выращивания джунов «с нуля». Но сейчас пришли к пониманию, что уже есть сформированный рынок junior-разработчиков и бизнес должен учиться это использовать.

Какой путь мы прошли, какие инсайты получили и как устроена наша работа с джунами сейчас — расскажет наша HRD Катя Земцова на «Стачке». Конференция проходит уже в 11 раз. В этом году 12-13 апреля в Ульяновске на базе УлГПУ соберутся 3000+ разработчиков, маркетологов, дизайнеров, руководителей и собственников IT компаний, HR и другие специалисты IT сферы.

Уже в субботу, 13 апреля, в 12.00 МСК расскажем о наших инструментах, процессах и текущих результатах работы с джунами. Зал: Кадры, секция: HR

Приезжайте Ural Digital Weekend 2024!

2-3 августа в Перми пройдет Ural Digital Weekend 2024 — конференция про разработку, управление разработкой и управление бизнесом веб-разработки. Лучшая конференция для быстрого погружения в бизнес веб-разработки с самым плотным нетворкингом, рекордным количеством открытий и знакомств с крупными IT-предпринимателями, корпорациями и продуктами. Организаторы: Spectr и Тэглайн.

В этом году программа будет разделена на 3 секции: «Разработка», «Управление разработкой» и «Управление бизнесом».

СЕКЦИЯ «УПРАВЛЕНИЕ БИЗНЕСОМ»
Программа бизнес-потока Ural Digital Weekend ориентирована на фаундеров и топ-менеджеров digital-продакшнов (ИТ-компаний, которые занимаются разработкой цифровых продуктов на заказ) и отвечает на вопросы о том, как быстрее, консистентнее и стабильнее расти в бизнесе веб-разработки. Акцент Ural Digital Weekend в 2024 году — системный менеджмент в продакшне: организационная структура, бизнес-процессы, финансовые и нефинансовые метрики, управленческий учет и делегирование.

СЕКЦИ «УПРАВЛЕНИЕ РАЗРАБОТКОЙ»
Прикладные доклады про управление и организацию процессов разработки цифровых продуктов: планирование, метрики, гибкие методологии, инженерные процессы и их оптимизация, управление людьми, формирование и развитие команды, инструменты управления и повышение эффективности разработки. Секция ориентирована на Product менеджеров, Project менеджеров, Delivery менеджеров, тимлидов, scrum-мастеров и всех, кто так или иначе связан с управлением и организацией процессов разработки.

СЕКЦИЯ «РАЗРАБОТКА»
В секции «Разработка» традиционно будут представлены прикладные доклады по направлениям Backend, Frontend, DevOps/SRE, ML/AI, Developer Experience.


ГДЕ И КОГДА
Место — Пермь, Digital Port (тот самый лофт из 2023 на берегу Камы с крутыми видами).
Все активности пройдут в уже привычном формате:
— в четверг (1 авг) вечером неформальное препати by Alto.codes
— в пятницу (2 авг) основная конференционная часть с докладами и after-party
— в субботу (3 авг) отдых и этно-экскурсия по Перми

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

Программный комитет уже активно работает, но пока еще (до конца апреля) можно подать заявку на доклад.

Цена участия будет стремительно повышаться вплоть до старта конференции (покупайте уже сейчас!).

Можно принять участие в качестве партнера. Чем раньше вы примите решение об участие в качестве партнера, тем больше будет охват: партнеры упоминаются во всех официальных пресс-релизах и всех-всех инфоповодах.

Отчеты о конференциях, прошедших в 2022 и 2023 годах, можно прочитать на vc.ru.

Всю информацию о конференции можно посмотреть на сайте Ural Digital Weekend 2024 и в официальном telegram-канале.

Приходите, приезжайте, подключайтесь!

Упомянутые ссылки
Сайт: https://udwe.ru
Официальный канал: https://news.1rj.ru/str/ural_digital_weekend
Партнерские опции: https://vk.cc/cwmjSE
Форма заявки на доклад: https://forms.gle/K6HkHwU4W4Epzify7
UDW 2022 на vc.ru: https://vc.ru/dev/495749-podrobnyy-otchet-o-it-konferencii-ural-digital-weekend
UDW 2023 на vc.ru: https://vc.ru/dev/950666-otchetnaya-statya-o-konferencii-ural-digital-weekend-2023

Оценка разработки. Неопределенности и «вилка»

Продолжаю рассказывать про процесс оценки в Spectr.
У каждой фичи, которую получили в результате декомпозиции всегда есть некий уровень неопределенности в ее понимании. И в зависимости от неопределенности меняется точность оценки по фиче и формируется вилка.

Ответьте на следующие вопросы, глядя на фичу:
— Целевой результат и бизнес-сценарий понятен?
— Способ реализации определен?
— В требованиях отсутствуют критические пробелы?
— Фича изолирована и не влияет на окружение и не имеет связей с другими фичами?
— В фиче есть интеграции со сторонними системами и протоколы обмена/доступы/документация по системам имеется?
— (дополняется)

Чем больше «нет» в этих ответах — тем выше уровень неопределенности.

Когда мы оцениваем трудоемкость по фиче, то для каждой компетенции (аналитика, фронт, бэк, QA, DevOps, UI/UX, менеджмент) в качестве базовой оценки ставим «наиболее вероятную» — ту, в которую верит человек, производящий оценку.

Далее на основе базовой оценки и уровня неопределенности по фиче мы формируем «вилку»: минимальное и максимальное значение потенциальной трудоемкости. Чем выше неопределенность, тем больше разбег между минимум и максимум.

Мы выделяем 3 уровня неопределенности: Low, High, Critical. Пример логики применяемых коэффициентов для формирования вилки приведен на скриншоте