Станислав Мешков

Делать правильные вещи VS Делать вещи правильно.

За время моего обучения в MBA, один из главных выводов, чему меня научили, это что есть большая разница, между "Делать правильные вещи" и "Делать вещи правильно".

Делать вещи правильно в разработке это:
- заложить правильную архитектуру,
- использовать аналитиков,
- планировать хорошо спринты,
- не менять приоритеты внутри спринта.

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

Разработка очень часто склоняется к "делать вещи правильно" - это связано с тем, что разработка - это инженерное дело, и ближе к модели "университета", чем модели "рынка". Владельца бизнеса\СЕО более склонны к подходу "делать правильные вещи" - они хотят максимизировать результат, и убрать неопределенность, как можно быстрее получив ответ с рынка, выйти туда первыми, и захватить как можно больше. Сочетать эти вещи можно, но для этого должны быть особые культура и доверие. Частный пример - стартапы раунда А или Б в силиконовой долине, или компании, предоставляющие услуги по разработке, которые работают с проектами с такой культурой, и смогли ее перенять.

#управлениеразработкой

Безопасность и качество кода.

Каждого клиента, что заказывает разработку у компании вендора, волнует то, как можно гаратировать безопасность и качество кода. Мы, в Umbrella, используем для этого Sonarqube, он проверяет каждую строчку кода на все известные уязвимости и стандарты, и подсвечивает проблемы деля их на 3 типа - критические, средние и мелкие. При наличии критических, он даже не даст сделать деплой, и подсвечивает все места которые надо улучшить. Те, кто работает с классными парнями из "ноунэйм технолоджи", услышат невнятное: "у нас очень опытные сотрудники, вы их прособеседуете". Это хорошо, что у нас есть отдел DevOps, который включает в себя DevSecOps. В этом мире ничто не гарантирует безопасность, но на 99% снизить риски можно.

Ещё одна причина делать сделку с правильной компанией разработчиком.

#управлениеразработкой

Первая постоянная работа.

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

P.S. Фото из +- той юности.
#мояистория

DDD Архитектура. Революция, которая сравнима с атомной бомбой.

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

Потому на смену микросервисной архитектуре пришла DDD (Domain-Driven Design) архитектура.

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

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

#управлениеразработкой

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

Новый функционал расписаний

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

#unspot. #нашстартап