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

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


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

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

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

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

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

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


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

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

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

Как мы внедряли добрые кубики НОРБИТ

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

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

В целом инициативу поддержали и дополнили своими идеями:

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

В итоге появился такой перечень:


Мы еще немного поработали над формулировками, купили кубики в Ашане и всем 120 сотрудникам департамента отправили информационное письмо (а копию напечатали в формате плаката и повесили рядом с коробкой с фигурками).

Первые результаты

Мы ожидали всего, что угодно, но инициатива получила удивительно быструю поддержку. Много фигурок обратной связи разошлось сразу после рассылки письма, а это было уже в 18:00. К 22 часам из 60 штук в корзине осталось меньше половины.


Первые дни эксперимента прошли достаточно спокойно. Из интересного:

• у нас было по три фигурки каждого вида и самыми дефицитными
• оказались зеленые фигуры с положительной обратной связью они всё время были заняты;
• поскольку кубики с положительной обратной связью никто не торопился отдавать, пришлось просить возвращать кубики на место;
• желтый кубики Нам кажется, ты забыл что-то важное ставил адресатов в ступор, так как вспомнить, про что конкретно ему пытаются напомнить, было не всегда просто;
• часть сотрудников восприняло идею как игру и очевидно некоторые кубики были поставлены в шутку;
• сотрудники предложили добавить кубики Мы рады, когда ты рядом с нами. Пожалуйста, не опаздывай и Мне очень нравится твой юмор, но иногда он звучит обидно.

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


Дополнительно сформировалась потребностях в еще двух фигурках:

• про опоздания Пожалуйста, предупреждай, если не успеваешь прийти вовремя;
• про жесткий юмор У тебя очень классные шутки, но иногда они ранят.

Неожиданные результаты и выводы

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

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

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

1. Эмоциональный интеллект, Harvard Business Review: 10 лучших статей, Альпина Паблишер, 2019
2. Как руководителю правильно давать обратную связь, чтобы не деморализовывать подчиненных, а стимулировать их к развитию, Артур Мурадян, генеральный директор транспортной компании TRAFT
3. Напрасные слова. Как давать обратную связь с учетом работы мозга, Анна Обухова
4. Жить дружно: советы авторитарным менеджерам и их подчиненным, Елена Витчак
5. Найдите кого-нибудь другого. Как неумение давать обратную связь сказывается на эффективности бизнеса, Матвей Горбачев
6. Can Your Employees Really Speak Freely, James R. Detert, Ethan R. Burris, Harvard Business Review, JanuaryFebruary 2016 Issue, перевод https://blog.bitrix24.ru/mogut-li-vashi-sotrudniki-govorit-vse-chto-dumayut/

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

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

Каждая из 10 рекомендаций на 2021 год направлена на развитие гибких навыков, являющихся ответом на вызовы прошлого года, а также специальных навыков, обусловленных задачами наступившего года. Кроме этого, в дополнение к описанным стратегиям, в текущем обзоре эксперты НОРБИТ делятся своим видением, над чем стоит работать ИТ-лидерам, чтобы повысить личную эффективность, и каким рекомендациям Gartner стоит уделить отдельное внимание.

Источник

1. Действуйте без сожалений

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

2: Будьте виртуозом виртуального пространства

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

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

3: Играйте на опережение

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

4. Думайте нестандартно

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

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

5. Поддерживайте идеи нейроразнообразия

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

6. Внедряйте принципы устойчивого развития

Повестка Gartner для ИТ-директоров 2021 года показала, что 62% руководителей в какой-то мере участвовали в реализации политики устойчивого развития в своей организации. Подумайте о том, как ИТ-команда может поддержать эти инициативы, от изменения вашего взгляда на процесс цифровой трансформации и постановки вопросов, касающихся устойчивого развития, до ускоренного развития данных и аргументов, связанных с экологической устойчивостью.

7. Будьте осознанным лидером

2020 год был трудным для всех, и по мере того, как ИТ-директора вступают в 2021 год, важно проанализировать, почему организации действуют определенным образом. Подумайте, например, почему организационные структуры не так сильно отличаются от того, как они выглядели 200 лет назад, или почему потребовалась пандемия, чтобы перейти на гибридную и удаленную работу. Начните с вопросов и будьте более честными с собой, оценивая свои взлеты и падения. Это позволит создать культуру доверия и безопасности, а также станет поводом подумать об альтернативных способах ведения дел.

8. Смотрите глубоко

Есть много видов горя от потери любимого человека до потери работы. И в каждом случае потеря чего-то конкретного (например, работы) сопровождается т.н. вторичными потерями. Так, потеря работы может быть связана с потерей профессиональной идентичности, распорядка дня или времени, проведенного с коллегами. ИТ-директора должны научиться распознавать такие вторичные потери в своей жизни и в жизни своей команды.

9. Будьте добры к себе

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

10: Найдите время, чтобы тестировать новые технологии

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

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

* * *

Нужно ли на 100% придерживаться всех этих трендов в 2021 году? Мы в НОРБИТ считаем, что, конечно, нет. Вот что порекомендовали бы мы.

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

А что бы порекомендовали ИТ-лидерам в этом году вы? Давайте обсудим это в комментариях.

Всем привет!

В НОРБИТ мы занимаемся SRM-решениями. Сегодня расскажем про особенный для нашей команды проект разработку BPMS-платформы NBT. Мы не просто создали бизнес-решение для заказчика, а разработали собственный продукт с нуля, всё это подразумевает совершенно другой подход к проектированию, разработке, управлению командой, организации процессов доставки изменений и планирования выпусков.

В общем, в статье не только красивая КДПВ. Ещё вы узнаете:

• про наш опыт проектирования микросервисной архитектуры (выбор инструментов, подходов к использованию этих инструментов, а именно абстрагирование их использования);
• про разработку конструктора бизнес-объектов и внедрение в решение конструктора бизнес-процессов для обеспечения подхода Low-code development;
• про то, как мы организовали работу над проектом и избавили разработчиков от некоторых рутинных или отвлекающих их аспектов при работе над системой (абстрактные межсервисные взаимодействия, автогенерация кода, атмосфера в команде);
• и про то, какой мем помогал нам в сложные периоды.

Источник

Наше подразделение в компании НОРБИТ занимается преимущественно автоматизацией закупочных процессов, для чего создает разного рода решения на платформе .Net.

Разработка таких решений начиналась еще на ASP.NET WebForms, затем новые версии этих решений создавались уже на базе ASP.NET MVC. Помимо разработок на .NET у нас были и есть другие проекты и решения, но все же разработки на .NET составляют около 80% от всех проектов подразделения.

Ограничения как ASP.NET WebForms, так и ASP.NET MVC предполагают, что для функционирования решений на этих платформах обязательно требовалось развертывание на ОС семейства Windows Server, а на стороне БД (базы данных) был реализован объем логики, не позволявший быстро и безболезненно перейти на СУБД, отличные от MS SQL Server. Это не предусматривало каких-то препятствий и сложностей до начала массового перехода на отечественное ПО.

Начиная с 2014-2015 годов, ИТ-рынок очень серьезно стал двигаться в сторону импортозамещения, и перед нами достаточно остро встал вопрос развертывания наших систем на операционных системах и СУБД, которые бы подходили под новые требования. По сути это стало вопросом 1, который нам потребовалось решить, чтобы наши решения могли закрывать требования потенциальных заказчиков в долгосрочной перспективе.

При этом, имея сильные компетенции и достаточно большую команду .NET-разработчиков, начинать разработку нового кроссплатформенного ядра не на .NET не представлялось рациональным. Выход платформы .NET Core с открытым исходным кодом для нас оказался весьма кстати, в том числе из-за его совместимости с такими операционными системами, как Windows, Linux и macOS.

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

Связан он с двумя аспектами.

1. Для кастомизации наших решений в проектах мы обычно разделяли уровень ядра (базового решения) и какие-то особенности, связанные с конкретными внедрениями, запросами от заказчиков, выносили на уровень настроек. Но при этом реализация этих отличий, например, наличие отдельных атрибутов или бизнес-правил в том или ином объекте системы, все равно требовала написания отдельного кода, вынесение в настройки этих атрибутов или бизнес-правил.
2. В последние годы все больше и больше набирает популярность подход Low-code development, по сути, встроенных в разного рода решения конструкторов, позволяющих на лету создавать и настраивать бизнес-объекты и бизнес-процессы.

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

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

Проектирование

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

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

На этапе проектирования нам пришлось переосмыслить тот факт, что мы не всегда знаем заранее, кто наш потенциальный заказчик, большой он или маленький, требовательный или лояльный, какие у него бизнес-процессы, какая инфраструктура. Часть требований к будущей системе начали всплывать сами собой: нужно масштабирование, нужна кроссплатформенность, нужна гибкая и быстрая настройка бизнес-объектов/бизнес-процессов, интерфейса, вероятно, вагон и маленькая тележка интеграций. Стало страшно, очень страшно.

Наша любимая картинка

Но, как говорит один из наших тимлидов: Слона нужно есть по кусочкам, начиная с лапки. Мы поставили на этом этапе перед собой две задачи: выбор микросервисной архитектуры и выбор инструментов. Да, именно сразу микросервисной (Мартин Фаулер рекомендует MonolithFirst, но мы его решили ослушаться), потому что с монолитами мы уже давно на ты и пришло время принять вызов двигаться дальше. А если серьезно, то одного только требования горизонтального масштабирования системы вполне достаточно, на наш взгляд.

Выбор архитектуры и инструментов

При проектировании архитектуры мы преследовали несколько целей:

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

Поскольку наша команда специализируется на технологиях Microsoft, в качестве платформы для реализации был выбран .NET Core версии 2.1. На тот момент, когда начиналась разработка нашего продукта, эта версия была LTS (long term support), и для нас это было важным критерием, так как некоторые отечественные ОС (на которых мы потенциально могли бы развертывать систему) поддерживают только .NET Core версии LTS.

Frontend решили делать на React + TypeScript, так как он прост в изучении. Мы решили пропагандировать подход full stack разработчиков.

Межсервисное взаимодействие мы решили сделать синхронное, потому что цепочки вызовов у нас предполагались недлинные, а межсервисное взаимодействие всё равно абстрагировано. Сервис вызывает другой сервис через абстрактный proxy. А в нем может быть любая логика. В нашем случае это вызов другого сервиса по http через Service Discovery. Подобная конструкция позволила нам, с одной стороны, упростить жизнь разработчикам (они могут просто использовать интерфейс сервиса для того, чтобы его вызвать, но на самом деле в контейнере служб ASP.NET Core зарегистрированная реализация этого интерфейса тот самый Proxy), а с другой обеспечить горизонтальное масштабирование системы автоматически, так как мы всегда спрашиваем у Service Discovery, как вызвать сервис, а тот, в свою очередь, может отдать один из запущенных инстансов этого сервиса.

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

Процесс выбора инструментов был тоже достаточно интересным. Нам предстояло решить какой функционал мы пишем сами, а какой берем из коробки (речь о существующих инструментах), но, конечно, абстрагировав всё взаимодействие с ним, чтобы при необходимости была возможность заменить этот инструмент или библиотеку на другую реализацию. Нам были нужны следующие инструменты: поисковый движок, движок бизнес-процессов (BPMN Engine), протокол обнаружения сервисов (Service Discovery), планировщик. Критерии были разные: лицензии, скорость работы, скорость погружения проектной команды и т.д. В результате получился следующий список: Elasticsearch, Camunda, Consul, Hangfire.

Сразу же заложили поддержку как минимум PostgreSQL и SQL Server, но ориентировались в основном на PostgreSQL и на развертывание под Linux. Свободное ПО, ну вы понимаете. В связи с этим произошла курьезная история. Поддержку SQL Server мы заложили на ранних этапах, но особо не рассчитывали, что кто-то из наших потенциальных заказчиков заинтересуется развертыванием на Windows + SQL Server, поэтому отложили тестирование этой конфигурации на потом (ведь всегда заранее известно, какая среда у заказчика?!). И вот однажды, делая очередной тестовый стенд для потенциального заказчика, мы уже были готовы как обычно развернуть AltLinux + PostgreSQL, но неожиданно узнаем, что заказчик все же передумал и решил развертываться на Windows + SQL Server, и у нас есть два дня, чтобы всё подготовить. К счастью, пригодился давно написанный и забытый код, который эту поддержку нам обеспечивал с небольшими доработками, и мы успели подготовить всё вовремя, и система заработала как ни в чем ни бывало (слава .NET Core).

Реализация бизнес-идей

К реализации мы подошли с подготовленным списком этапов работ, и самым принципиальным из них был получение в ближайшей перспективе MVP (minimum viable product минимально жизнеспособный продукт). Мы практически с первых итераций начали работать с акцентом на как можно более быстрое получение прототипа с визуальной частью, которую можно демонстрировать заказчикам (коими вначале были наши руководители) периодически. Этот подход ожидаемо способствовал переосмыслению некоторых задуманных ранее концепций. Удалось выловить несколько противоречий и побороться с ними заблаговременно. Речь идет о проектировании Web API для взаимодействия frontend и backend.

Конструктор бизнес-объектов

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

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

Создание нового бизнес-объекта (шаблона). Поля бывают разных типов

Заполнение свойств поля. Состав свойств изменяется в зависимости от типа поля

Реестр и фильтр строятся на основе метаданных, заполненных при создании структуры бизнес-объекта

Реестр событий

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

Настройка события для поля (это может быть валидация, условие или вычисление)

Конструктор бизнес-процессов

Как мы любим повторять: Кому нужны бизнес-объекты без бизнес-процессов?. Сказано-сделано. Мы, конечно, знали заранее, что наступит момент, когда нужно будет решать и вопрос бизнес-процессов, и эта задача наводила ужас была чем-то загадочным и мистическим ровно до тех пор, как мы не взялись за нее. Посетив несколько митапов, прочитав и попробовав пару инструментов, мистика развеялась. Было решено использовать движок Camunda (конечно, выполнив все наши процедуры по абстрагированию доступа к этому инструменту). Это замечательный инструмент, который мы всё ещё продолжаем познавать и наращивать варианты его использования.

Текущее положение бизнес-объекта в бизнес-процессе

Результаты

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

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

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

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

P.S. Сложно в одной статье описать всё детально, поэтому она получилась больше обзорной. Очень надеемся, что вы нашли в ней что-то интересное, и мы с удовольствием ответим на возникшие вопросы в комментариях, или опишем какой-нибудь аспект нашей системы более подробно в отдельной статье.