По для производства

Что сложнее: запустить стартап-проект в чистом поле или встроить его в готовый продукт? На самом деле одинаково сложно все.

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

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

Хочу рассказать о том, как проходит запуск нового направления МоегоСклада Производство 2.0. С точки зрения бизнеса тема очень любопытна и интересна. Рассказываю в прямом эфире. Эта статья мой взгляд на результаты первых двух недель работы, поэтому смогу погрузить в костер событий и не упущу ни одной шутки.



Краткое содержание:

• Мы
• Откуда берутся бизнес-требования
• Проектируем, предсказывая будущее
• Производство гробов и модель данных
• Как не сломить найти общий язык с бизнес-аналитиком, если ты архитектор
• Мы проработали, но нет. Автомобиль и рыба. Что общего?

Компания МойСклад более 13 лет развивает и продает веб-сервис, упрощающий жизнь малому и среднему бизнесу. Сервис помогает вести складской учет, управлять продажами и закупками, печатать необходимые для ведения бизнеса документы и много-много всего. У нас налажен и постоянно развивается процесс разработки. Сделанные в первый день работы тикеты (на общепринятом языке задачи) могут уже завтра быть на проде. Продукт большой и сложный, пользователи активно делятся пожеланиями. Мы придумываем, как сделать полезный для людей сервис и делаем. И сейчас обновляем блок производства! Мы команда Производство.

Действующие лица первого этапа:

• Аскар генеральный директор
• Олег технический директор
• Максим product owner, направляющий нас
• Тимур бизнес-аналитик, который знает процессы производства
• Максим тимлид команды разработки
• Я системный аналитик

Вводная

Перескажу кратко вводную, которую в первый день спринта, 22 октября 2020-го, мы услышали от Аскара.

Производство в МоемСкладе есть уже давно и у него есть пользователи. Но оно сделано в минимальном исполнении. Можно создавать технологические карты и на их основе либо резервировать товары на складе под производство, либо одномоментно списывать товары и производить готовую продукцию. Это все.



Длительное время отдел продаж и техническая поддержка транслировали жалобы и пожелания по улучшению производства от пользователей. Несмотря на наличие такой обратной связи, количество пользователей растет. Производство часто запускают в действующих организациях, которые уже ведут учет с МоимСкладом и не хотят менять его. Это одна из основных причин, по которым число пользователей текущего производства растет: работа с двумя программами вызывает негодование.

В феврале 2020 года в МойСклад написал Тимур (теперь уже наш бизнес-аналитик), работавший тогда с учетом на реальном производстве, с описанием как должно быть, прототипом и предложением о сотрудничестве. В итоге Аскаром принял решение подойти к развитию этого направления основательно и запустить Производство 2.0 обновленное и умное.

Займемся производством

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

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

• Просмотреть весь запланированный бэклог, чтобы предсказать будущее осознать что нас ждет
• Спроектировать модель данных, чтобы определить базовые сущности, встроиться в текущую модель и избежать катастрофических миграций в будущем
• Определить законченные пользовательские сценарии, ключевые функции
• Сделать протоипы UI по итогам анализа и проектирования
• Создать задачи на разработку и делать

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

Что помогло сделать первый шаг?

Макеты интерфейсов в виде Excel-таблички, которые нарисовал Тимур, наш бизнес-аналитик представитель пользователей МоегоСклада, который пользовался им не так много, как мы. Его представление о продукте помогает понять, что люди хотят видеть на экране, а свежий взгляд приносит интересные идеи, заменяя наше давайте переиспользуем. С применением этих макетов мы начали трогать процессы и проектировать логическую модель данных.

Рекомендация: перед проектированием системы изнутри, нарисуйте макеты пользовательского UI в любом виде, хоть карандашом на A4. Да, они 100 раз поменяются, и вообще нормальный UI/UX дизайнер потом все исправит, но они должны появиться, чтобы помочь.

На ней все держится. Модель данных

Пока мы проектировали модель данных, мы нашли все возможные проблемы, которые только могут возникнуть, определили все основные процессы, которые она должна покрывать. На модели мы проверили полный список известных бизнес-требований.

Если этот шаг не сделать на старте проекта, то есть шансы в какой-то момент открыть Америку или переделать все. Модель данных это что-то элементарнее фундамента, это Земля, а на ней держится вообще все.

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

В целом обсуждение было построено примерно так:

1. Для очередной сущности я спрашиваю: Что это такое? и Что мы с этим можем сделать?.
2. Тимур рассказывает нам о связанных процессах, показывает макеты, приводит примеры.
3. Все задают много-много вопросов: А можно так?, А что, если...?, удивляются, и иногда кричат Так нельзя!.
4. Тимур убеждает, что можно и очень надо.
5. От примера про сборку шкафа мы переходим к примеру про гробы (А если мы производим гробы из австралийского дуба, и нам заказывают модификацию из сосны...).
6. Смеемся, приходим к компромиссу, дорисовываем в модели данных связанные сущности, описываем ключевые параметры, оставляем заметки уточнить позже.
7. Фиксируем в статье Вопросы и ответы решения по бизнес-требованиям и ограничениям, если они появились в процессе обсуждения или наоборот, если были сняты.

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



Рекомендация номер два. Если стартап запускается с нуля, то простор для творчества есть и можно брать любых опытных разработчиков с рынка труда. При создании стартапа в готовом продукте, команда должна хотя бы базово знать его, уметь исследовать и не бояться этого. Не запускайте на ранних этапах внутренние проекты с новыми людьми это может быть опасно для существующего продукта. Мы с Максимом ранее работали в других командах МоегоСклада. Для Максима роль тимлида это рост внутри компании. Мое назначение в МоемСкладе: исследовать все и везде. Поэтому вопросов у нас к Тимуру было много. Чем больше вопросов, тем больше ответов. Чем больше ответов, тем больше шансов получить более надежное решение.

Убей в себе архитектора и научись слышать

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

Что разработчики хотят от бизнеса на ранних этапах? Уверенности! Мы много раз разбивали уверенность Тимура о скалы и уводили его от задуманных бизнес-требований к попыткам сделать из того, что есть, или сделать проще. Так нельзя!

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

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



Рекомендация номер три: разработчики от бизнеса ждут уверенности. Если вы бизнес-аналитик и представляете бизнес, или же вы бизнес-заказчик, будьте тверды в своих решениях до последнего, что бы разработчики не говорили. Проще не значит правильно! Если сделать проще сегодня, то завтра доработки выльются в очень большие суммы. Лучше потратить чуть больше в начале и вылить на своего разработчика всю душу (пожелания), чем потом страдать. Разработчик должен знать о потенциальном будущем!

Не откладывай на завтра. НИКОГДА!

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

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

Еще одна ошибка Мы знали, что надо было проверить на проде процент пользователей-разборщиков, но тянули до последнего, хотя уже даже SQL-запросы подготовили. Если на проде есть прототип и можно проверить теорию на реальных данных, проверять надо сразу!

Если бы я не писала, а говорила, то это звучало бы как (читать с выражением): М Ну Как бы сказать Короче Вот Каждый третий.

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



Из-за чего эта ситуация произошла? Мы все знали, что в текущем производстве такое возможно, но вести учет по таким техкартам проблематично. Несмотря на наличие примера про разборку автомобиля от Максима, нашего продакта, Тимур убедил: это редкий кейс и вообще таких пользователей мало. Олег был сразу против отказа от такой возможности. Именно по его подсказке мы, наконец, добрались до прода, чтобы проверить гипотезу. Да и я на этом демо архитектуры вспомнила про разборку рыбы на голову, хвост и филе.

В завершении первого спринта мы пришли-таки к окончательному решению, и уже совсем скоро наша модель данных позволит детально проектировать и начинать разработку. Макеты детализируются, подключаем коллег по тестированию и UI/UX. Продолжаем творить!

Итого

Чтобы успешно и быстро начать стартап-проект:

1. Изучите весь известный бэклог, чтобы знать будущее.
2. Выберите фундаментальную задачу, которая делает/меняет все.
3. Для внутреннего стартапа нужно подключать команду с опытом решения других задач в развитии продукта.
4. Слушайте бизнес и дайте вашему бизнес-аналитику эликсир уверенности. Бизнес-требования важнее системных ограничений. Системные ограничения всегда можно преодолеть (это точно)!
5. Прежде чем что-либо проектировать, посмотрите на систему глазами пользователей нужны черновые макеты UI, которые обязательно будут изменены.
6. Проектирование нужно начинать с модели данных
7. Если есть возможность проверить теорию, проверяйте сразу, не откладывая до последнего.

О производстве в МоемСкладе

Всем привет! Я ведущий системный аналитик в компании МойСклад и сейчас мы с командой Производство запускаем внутренний стартап внутри стартапа Производство 2.0. Недавно я написала о том, с чего начать процесс разработки в новоиспеченном проекте, а сейчас хочу продолжить рассказ из горящего танка.

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

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



Нужно было переосмыслить бизнес-процессы, чтобы внести уточнения в модель данных и прототипы UI. Примеры про разборку рыбы и автомобиля мы применяли достаточно часто, но эмоционального фона диалогам они особо не придавали. Да и с учетом уточняющихся на ходу бизнес-требований команда устает уже после первого часа обсуждений. Нас пока мало от 4 до 6 человек на онлайн-встречах. Важно держать внимание, чтобы каждый участник был максимально вовлечен в процесс проектирования: разработчик и системный аналитик оценивают реализуемость, тестировщик помогает найти подводные камни, бизнес-аналитик и владельцы продукта помогают разбирать бизнес. Всеобщая концентрация может даваться тяжело, особенно, если транслирует экран и дорисовывает модели / дописывает требования только один человек.

Но все выглядит более ярко, когда в голову приходит интересный пример, пример, с коровой (обсуждения не имеют никакой связи с реальной жизнью участников команды, мы уважительно относимся к животным):

Так, давайте представим, что у нас мясной цех и мы разбираем корову.

Немного определений

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

Группа продукции это совокупность товаров (кортеж), который будет произведен в результате выполнения технологического процесса.

Ресурс товар, из которого производят продукцию.

Техкарта определяет процесс производства группы продукции и является шаблоном в части определения необходимых ресурсов.

Техпроцесс производства упорядоченная последовательность этапов, в результате выполнения которых производится продукция и затрачиваются ресурсы.

Техоперация документ, созданием и проведением которого пользователь инициирует одномоментное списание ресурсов со склада и зачисление готовой продукции на него.

Техкарта коровы

Ключевыми сущностями производства, от которых строятся все процессы, являются товар, этап, процесс и техкарта.

Нужно представить все возможные виды техкарт, которые мы можем получить. При производстве коровы.

Вариант 1: У меня есть мясной цех и луг. Я забираю корову с луга и за один этап превращаю ее в части. Это простая техкарта разборки.



Вариант 2: У меня есть мясной цех и луг. Я покупаю части коровы, отвожу их в мясной цех, и мгновенно собираю 1 целую корову. Это одноэтапный процесс производства коровы по техкарте сборки. Короче, то же самое, что со шкафом из известного желто-синего магазина: медленно вкручиваю шурупы, куда найду и сколько хватит.



Это простые техкарты, которые поддерживает текущее производство МоегоСклада. А теперь усложним.

Вариант 3: У меня есть мясной цех, упаковочный цех и луг. Я забираю 10 коров с луга. Сначала я превращаю 10 коров в очень много частей этап разборки, затем сортирую полученные части этап сортировки, а после помещаю в упаковки. Это все делается по сложной техкарте разборки коровы. Полученная техкарта:

Ресурсы: 1 корова, 100 м2 вакуумной упаковки.
Готовая продукция: 1 упакованная лопатка, 1 упакованная печень, упаковка на 2 стейка

Производственный процесс:

1. Этап разборки (Ресурсы: 1 корова)
2. Этап сортировки (Ресурсы: нет новых ресурсов, используются результаты этапа разборки)
3. Этап упаковки (Ресурсы: 100 м2 вакуумной упаковки)

Получается, что я могу взять с луга как одну корову, так и 10, и 20 и т.д. И этот прекрасный вопрос бизнес-аналитику: Тимур, а можно произвести 1,5 коровы?. Истерика. Ответ: Можно. Мы же не только с коровами работаем, ограничения не ставим. Захотят пол коровы, возьмут половинку с луга или из морозильника.



Вариант 4: У меня есть мясной цех, завод по производству колокольчиков и луг. Мне привезли части коровы, я провожу этап сборки и получаю одну корову, которая не ходит. Делаем этап реанимации, производим для нее колокольчик и отправляем корову на луг. Это сложная техкарта процесса сборки коровы с колокольчиком.

Да, 1,5 коровы тоже допускаем.

Полученная техкарта:

Ресурсы: 1 упакованная лопатка, 1 упакованная печень, упаковка на 2 стейка, серебро.
Готовая продукция: 1 корова, 1 колокольчик.

Производственный процесс:

1. Этап сборки (Ресурсы: 1 упакованная лопатка, 1 упакованная печень, упаковка на 2 стейка)
2. Этап реанимации (Ресурсы: нет новых ресурсов, используются результаты этапа сборки)
3. Этап производства колокольчика, может идти параллельно этапу реанимации (Ресурсы: серебро)
4. Этап надевания колокольчика на корову (Ресурсы: нет новых ресурсов, используются результаты предыдущих этапов)

Такая модель помогла нам доопределить бизнес-правила и ограничения:

• Можно ли в простой техкарте сборки установить норму готовой продукции 1?
• Могут ли быть готовые продукты по результатам промежуточных этапов?
• Можно ли задавать не целые нормы?

И много-много других.

И конечно, мы окончательно определились с кусочком монстра модели данных.

Техоперация и производственный процесс

Теперь нужно было определиться с тем, как ведется производственный процесс по описанным техкартам в части контроля остатков на складе и документооборота.

Сейчас, имея только техкарты видов 1 и 2, мы можем резервировать корову или ее части на складе, используя заказ на производство. Чтобы списать корову со склада и превратить ее в части коровы или наоборот, мы создаем техоперацию. Заказ на производство ничего не зачисляет на склад.

Представим, что к нам пришел заказчик и попросил нас произвести для него части коровы. Мы, как производитель, регистрируем заказ на производство. В заказе на производство мы выбираем нужные части коровы.

Утверждения, вопросы и ответы:

Утверждение от бизнеса. Вы, как производитель, можете отслеживать процесс производства коровы поэтапно.

Вопрос. Могу ли я просто зарегистрировать, что было производство коровы, без контроля по этапам?

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

Вопрос. А что, если техкарта коровы создана на ногу, голову, стейк бедра и хвост, а заказать у нас хотят только ногу из этой техкарты?

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

Вопрос. А можно ли в заказе на производство донастроить техкарту так, чтобы в нем была только нога?

Ответ. Нет, тогда нужно создавать новую отдельную техкарту. Пример Техкарта Лопатки коровы

Вопрос. А можно ли в заказе на производство донастроить ресурсы из техкарты, увеличив количество коровы с 1 до 1,2 и добавить до ресурсы?

Ответ. Да, можно, потому что может быть брак, может приехать корова побольше и т.д.
И так далее.




По итогам обсуждений были введены новые термины и определения в производстве мясной продукции:

• Кортеж готовой продукции (коровы) неизменяемая группа готовой продукции, указанная в качестве результата производства по техкарте.
• Сборка (коровы) процесс производства, в результате которого получается одна готовая продукция при любом количестве ресурсов.
• Разборка (коровы) процесс производства, в результате которого получается более одной готовой продукции при любом количестве ресурсов.
• Техоперация (над коровой) мгновенное производство в один этап.
• Техпроцесс производства (коровы) поэтапное производство (приготовление) коровы
• Проблематика коровы

В заключении

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

Гораздо интереснее разбирать бизнес-требования и проектировать не на типичных примерах, а на тех, которые могут заставить смеяться до слез.

Во-первых, это весело.

Во-вторых, это заставляет фантазию работать более креативно и извлекать из головы правильные вопросы.

В-третьих, все участники команды бодро подключаются к проектированию и придумывают свои версии производства.

Не будьте скучными и выбирайте примеры правильно!