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

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

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

1. Перечислить ключевые параметры, которые влияют на продажи: SLA, функционал - что угодно, чтобы привязать виртуальные задачи к реальному миру.

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

3. Определить узкие места системы, которые вызывают проблемы с масштабированием и доступностью.

4. Согласовать среднесрочные цели IT-команды с высшим руководством.

5. Создать рабочий процесс на инструментах командного взаимодействия - таких, как доска, трекер, мессенджер, репозиторий.

6. Организовать процесс найма и вхождения в проект новых разработчиков.

7. Наладить системы мониторинга и бекапа.

8. Сделать декомпозицию среднесрочных задач по этапам и написать календарный план.

9. Сделать CI/CD.

10. Написать план изменения архитектуры.

11. Выставлять приоритеты задачам в беклоге.

12. Наладить регулярные встречи IT-команды с продактом и отчеты высшему руководству.

А где разработка? Ответ - весь список. Все это входит в Жизненный цикл ПО".

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

Все перечисленное связано с деньгами.

1. Ключевые параметры, которые влияют на продажи: трафик, конверсия, возвраты, сколько клиентов возвращается, сколько уходит, и так далее. Мы все любим исследования, обсуждать культуру разработки, спорим из-за стандартов, но оценка IT-компаний - это произведение годовой выручки или размера клиентской базы на мультипликатор, и код не принимается во внимание вообще. Задачи разработки должны быть привязаны к важным измеримым параметрам бизнеса. Я принимал участие в разработке множества проектов, и помню несколько случаев, когда владельцы-управляющие растущих проектов игнорировали серьезные изменения ключевых параметров. Один проект терял трафик из-за конкурентов, у другого выросли возвраты денег за оплаченные покупки. Игнорирование этих проблем разрушило проекты всего за несколько месяцев после многих лет работы. Несмотря на то, что технически эти проекты надежны, и до сих пор приносят небольшие деньги, доля рынка потеряна навсегда. Обратную ситуацию я помню в корпорации Oracle. Каждому сотруднику: разработчику, тестировщику, менеджеру рассказывали о том, сколько миллионов долларов выручки у продукта, над которым они работают, какая рыночная доля, сколько клиентов пришло, сколько осталось, кто конкуренты, и так далее. Были общие собрания, на которые приезжали вице-президенты, и делали для коллектива тот же доклад по результатам, который они делали перед советом директоров. Как можно видеть по отчетам Oracle corp, такая концентрация на результатах работает очень хорошо.

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

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

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

5. Процесс разработки с доской, трекером задач, системами контроля версий, совещаниями, проектированием, code review, сборкой, тестированием и выкладкой - естественный для большинства команд. Мы просто не можем предсказуемо и постоянно выкладывать в работу задачи и соблюдать SLA - процент времени доступности системы, без надежных процессов разработки.

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

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

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

9. Выгода от непрерывной разработки и непрерывной доставки (CI/CD) не очевидна. По закону Лемана, сложность программного обеспечения растет вместе с развитием системы, если не принимаются меры по сдерживанию роста сложности. CI/CD - это усилия команды разработчиков по сдерживанию роста сложности. Покрывая код тестами и запуская их на стендовых серверах при сборках, мы сдерживаем рост затрат на разработку. Эта задача находится внизу списка потому что она оправдана только для растущих и успешных проектов. Для большинства обычных проектов достаточно выкладки из релизной ветки git. Если растем без CI/CD - тоже ничего страшного, однако, нужна команда QA такого же размера, как команда разработчиков, удваивается площадь офисов, количество техники и менеджеров на совещаниях. Проект будет медленнее расти, но на растущем рынке можно не замечать этого годами. Я знаю несколько крупных проектов без тестов, в каждом тратят сотни тысяч долларов в год на переписывание тех частей кода, которые не были покрыты тестами.

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

11. Выставлять приоритеты задачам в беклоге можно по-разному, нет единого правила для всех. В методологии SCRUM приоритеты выставляет команда на planning-совещаниях. В традиционных моделях приоритеты выставляет руководитель команды. У руководителя-чайки нерегулярность изменения приоритетов приводит к отсутствию приоритетов вообще. Людям удобнее работать, когда они знают правила определения приоритета задач. Когда правила известны, люди учатся выполнять более важные задачи, чтобы чувствовать себя важными.

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

Итак, сколько времени займет сделать веб-сервис? Чаще всего, ответ будет "Возьмите Wordpress, как поступили 38% веб-сайтов в интернет. Зачастую задачу можно решить без команды программистов. Можно использовать SAAS, взять коробочное решение или отдать задачу на outsource. Конечно, если вы не строите бизнес в IT. По законам Лемана, чтобы не отставать от конкурентов, разработка ПО должна продолжаться в течение всей жизни продукта. Когда бизнес будет расти, появятся управленческие и операционные процессы, архитектурные задачи, бизнес-анализ, юридические, бухгалтерские, финансовые процессы, связи с общественностью, корпоративные правила.

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

Секция Team на конференции DUMP про людей и для людей. В этом году не будет никаких скрамов и канбанов, зато будет много инструментов для повышения эффективности работы в командах. Мы поговорили с Григорием Петровым, DevRel из Evrone. Гриша - разработчик с 20-летним стажем, нейрофизиолог-любитель и технический евангелист. На DUMP он выступит с докладом Физиология мозга: рычаги управления личной эффективностью.

• Гриша, привет! На 10м юбилейном Дампе ты выступишь с темой про физиологию мозга и рычаги управления личной эффективностью. Мы ждали твой доклад целый год! Мы знаем, как ты много и с интересом исследуешь тему нейрофизиологии. Расскажи подробнее, о чем будет твой доклад?
  

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

• Методик для достижения личной эффективности описано много: состояние потока, однозадачность, тайм-менеджмент с учетом биоритмов и другие. Этого недостаточно?
  

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

• А какие методики по повышению личной эффективности ты пробовал на себе? Что зашло, а что не получилось?
  

  • Не хочу спойлерить доклад, поэтому отвечу обтекаемо. На себе я пробовал довольно много разных способов. Что-то работало, что-то не работало, от чего-то потом приходилось отмокать пару недель. Но такой опыт не очень масштабируем. Мне интереснее организовать работу моих коллег и других разработчиков так, чтобы они могли делать крутые штуки дольше, чем полчаса в день. О закономерностях, которые позволяют одним способам работать, а другим нет - в моём докладе.

• С чего началось твоё увлечение нейрофизиологией?
  

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

• Где ты берёшь информацию? Какими источниками пользуешься?
  

  • Учебники. 5-я редакция "Principles of neural science" у меня настольная книга: 1400 страниц, твердый переплет, 5 килограмм живого веса. Скоро ее заменит 6-е издание, а помогают учебники поменьше. PubMed, опять же. Ну и секретные telegram чаты нейрофизиологов, конечно. Куда же без них.

• Как ты используешь свои знания по нейрофизиологии в жизни и работе сегодня? Расскажи про свои ежедневные ритуалы.
  

  • Использую по назначению: объясняю себе, почему я делаю те или иные штуки. Что можно делать, чтобы вести себя так, как мне нравится, а не так, как получается. Ставлю над собой эксперименты и стараюсь сделать их хотя бы минимально научными. Что до ритуалов: есть работающие штуки, о которых хотелось бы рассказать на конференции, чтобы у гостей была возможность задать вопросы и обсудить все на afterparty. Так что не буду спойлерить: приходите и всё услышите.

• Что делать, если ты уже гуру планирования, но вот твоя команда...ещё прокрастинирует?
  

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

• Главное, что запомнит аудитория после твоего рассказа? Чем он будет полезен?
  

  • Собственно, весь мой доклад сводится к одной фразу: "мы делаем не то, что правильно, логично или разумно, а то, что привыкли делать". Но чтобы применить это заклинание на практике нужно будет послушать немного теории и занимательных историй про зрительную кору, когнитом и attention schema.

  

  БЛИЦ:

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

  • Не отвлекайте, я занят :)

• Есть ли у тебя увлечения, не связанные напрямую с it, кроме нейрофизиологии?
  

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

• Как ты переключаешься, как отдыхаешь?
  

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

• Твои слушатели получают гору полезности из твоих выступлений. А что работа с аудиторией даёт тебе?
  

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

• Что тебя мотивирует?
  

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

• Вернись на 10 лет назад, что себе посоветуешь/скажешь?
  

  • "Не води рейды в World of Warcraft, разочаруешься. Води разработчиков выступать - тебе понравится!"

• А кем видишь себя через 10 лет?
  

  • Мне бы хотелось задержаться в DevRel и научиться обучать разработчиков не только выступать, но и писать код. Каждый день я пользуюсь сотнями программных продуктов - хочется, чтобы их писали крутые ребята и девчата, которые знают, что делают. А чтобы они знали, их нужно обучать.

Есть ещё вопросы? Можешь задать их Грише 14 мая на конференции DUMP-2021! Билеты на офлайн/онлайн и программа выступлений здесь.

Весной 2019 года меня пригласили руководить разработкой в небольшой стартап, занимающийся обработкой Big Data.

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

Команда разработки включала в себя 10 сотрудников: тимлид, front-end разработчики, back-end разработчики, системный администратор и DevOps. Стэк разработки: Python, PHP, JavaScript. Мои глобальные задачи были стандартны, но это не делало их простым. Я упорядочил их по порядку решения задач:

1. Повысить качество и отказоустойчивость инфраструктуры

2. Повысить квалификацию разработчиков

3. Повысить качество ПО

Повышение качества и отказоустойчивости инфраструктуры

Проблема 1: Команда работала по старинке.Каждый разработчик сам управлял локальным окружением разработки. Это приводило ко всем знакомой ситуации при возникновении ошибок на productionе: у меня локально работало. Окружение должно быть единым для всех ваших окружений. С приходом контейнеризации (в частности, Dockerа) в массы, эта задача стала легко решаемой.

Решение: Контейнизируйте ваши приложения. Выберите единую ОС для вашего базового образа (на тот момент у нас был Ubuntu 18.04 LTS). Устанавливайте 3-rd party пакеты с точной версией, вплоть до хотфиксной. Пусть поддержкой занимаются системные админстраторы и DevOpsы, разработчикам делать там нечего.

Проблема 2: Много self-hosted сервисов, мало системных администраторов

Все проекты и их компоненты были на выделенных серверах, которые поддерживались двумя (а долгое время одним) системным администратором. Большая часть работы была рутинным админством: тут "подкрутить", там "отшлифовать".

Решение: Освободите руки системного администратора от рутинных задач насколько это возможно. Автоматизируйте свои процессы с помощью Terraform и Ansible. На уровне малого бизнеса/стартапа зачастую дешевле делегировать часть работы, чем нанять еще одного системного администратора. Возьмите managed СУБД и K8s, за одно решив таким образом такие проблемы как отказоустойчивость, масштабируемость и админством этой инфраструктуры.

Проблема 3: Вшитые в код ключи/пароли/сертификаты (секреты) от production сервисов

Решение: Внедрите систему хранения секретами, такой как Vault. Настройте политику доступа к этим данным. Перенесите все секреты из кода в хранилище и запрашивайте их при инициализации приложения.

Повышение квалификации разработчиков

На момент моего прихода в команде были в основном junior разработчики.

Проблема 1: Низкая квалификация разработчиков

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

Решение: Оставьте только талантливых людей (даже если они juniorы), которые быстро учатся и самое главное, хотят учиться. На остальных не тратьте время. Новичков вполне могут позволить другие крупные и состоявшиеся компании. Наберите вместо 5 новичков 2 хороших специалиста, которые будут качественно выполнять свою работу. Старайтесь находить тех, у кого вы бы сами могли чему-нибудь научиться в узкой области.

Проблема 2: Каждый разработчик пишет код в своем стиле

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

Решение: Дирижируйте свою команду. Прививайте разработчиков к единому стилю написания кода. Используйте линтеры типа we-make-python-styleguide (сборник плагинов к flake8) для поддержания единого стиля.

Проблема 3: Отсутствие технологического развития

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

Решение: Много читайте и постоянно следите за новинками вашей области. Внедряйте и обучайте этому вашу команду. Вместе с ростом квалификации вашей команды растет и ваша.

Повысить качество ПО

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

Проблема 1: Плохо спроектированный код

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

Решение: Внедрите DDD и Twelve-Factor App.

Проблема 2: Классы, классы и еще раз классы по всюду

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

Решение: Для группировки сойдут модули и пакеты. Функцию не обязательно оборачивать в класс. Прочитайте о YAGNI, KISS, а также о функциональном программировании.

Проблема 3: Слишком сложные для понимания автотесты

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

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

Заключение

Перемены, описанные выше происходили в течение 1 года. По всем 3 пунктам удалось добиться хороших результатов. Руководство осталось довольным.

С наступающим, Новым годом!

Приветствую дамы и господа! В этой статье я расскажу о JavaScript библиотеке Biscuit-store.

Описание

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

Основные цели статьи

• Рассказать о biscuit-store и его целях;

• Провести сравнение с другими подобными инструментами;

• Дать краткий обзор функционала.

Здесь я не буду погружаться под капот, а лишь проведу краткий обзор.

Плюсы biscuit-store

• Стремление к простоте исполнения;

• Поддержка React;

• Стремление к единому подходу;

• Асинхронность из коробки;

• Простое расширение через Middleware;

• Отсутствие зависимостей;

• Гибкая модульная архитектура;

• Оптимальное соотношение размера библиотеки и количества функций;

• Встроенный отладчик.

Характеристики

• Вес core- 18Kb, Gzip: 6.2кб (скомпилировано в CommonJs);

• Вес react модуля 6.8, Gzip: 2.0кб;

• Вес adapter модуля 9.6, Gzip: 3.5кб (скомпилировано в CommonJs);

• Проверено в браузерах:

  • Internet-explorer 11+;

  • Chrome 48+;

  • Opera 25+;

  • Mozilla firefox 40+;

  • Safari 9+.

• Включена поддержка TypeScript.

Для чего создавалась эта библиотека и зачем она нужна?

Чтобы понять мотивы создания библиотеки, надо посмотреть на существующие популярные инструменты для JavaScript state-management, а именно: redux и mobx.

Redux

Это легковесная библиотека, которая весит всего 2kB и представляет единый контейнер управляемых состояний для js приложения. Основными плюсами redux являются его малый вес и гибкость. C помощью redux можно разрабатывать приложения любого размера. Мне лично нравится эта библиотека.

Но дьявол, как известно, в деталях.

Все не так просто, как кажется

Когда смотришь пример кода на GitHub кажется, что все понятно. Но, когда дело касается применения в реальном проекте и если вы новичок, то у вас может вскипеть мозг. Вы просто не понимаете что, куда и как Судорожно начинаете искать в интернете статьи и видео-уроки чтобы понять, как собрать все паттерны воедино. Redux-utils конечно сглаживает эту проблему, но лишь частично.

Отсутствие асинхронности из коробки.

Вероятно, в 2015, когда создавалась эта библиотека, это не было столь значимо. Сейчас на дворе 2021 и асинхронность повсюду во вселенной JavaScript. Конечно, эта проблема частично решается через middleware, такие как redux-saga и redux-thunk. Но это порождает еще две проблемы: отсутствие единого подхода и увеличение зависимостей проекта.

Отсутствие единого подхода

Redux лентяй и прокрастинатор Он хочет что бы работу за него делали другие. Вам нужна асинхронность - подключайте отдельные библиотеки для слайд-эффектов, нужно избавится от лишних перерисовок - подключайте reselect, бесит писать reducers через switch подключайте что-то типа redux-actions. Весь этот зверинец и порождает отсутствие единообразия.

Лишние зависимости от сторонних библиотек

Тут буду немногословен: лишние зависимости - не есть хорошо.

Вывод

Redux - хороший инструмент, но, я бы сказал, что он слишком много сваливает на разработчика.

Mobx

Основной лозунг mobx:

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

Если redux - это лентяй и прокрастинатор, за которого нужно думать, то mobx - это скорее нарциссичный профессор в мире state-management. Он говорит: Я все сделаю за тебя, а ты только включи творчество и нарисуй архитектуру.
Автоматика это хорошо, особенно, если вы делайте одноразовый, быстрый проект, который после релиза уйдет в пыльный ящик или будет поддерживаться небольшой командой. Но если вы разрабатываете более крупный проект, над котором работают смеженные команды, то от всей этой архитектурной свободы вы скорее всего получите максимум боли Иной раз вы просто не сможете понять что, откуда тянется.

Ни в коем случае не воспринимайте всё вышесказанное как хейт. Это всего лишь моё субъективное мнение, о плюсах и минусах данных инструментов.

Теперь можно поговорить о Biscuit

Цель biscuit-store - как раз заполнить нишу между прокрастинатором redux и профессором mobx. Создать некоего работягу, который ходит на завод и вытачивает заготовки. Он однообразно делает свою работу, не задавая лишних вопросов.

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

Перейдем к практике

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

1. Создайте утку;

2. Донесите до утки, что она утка и должна, крякать, летать и плавать;

3. Научите утку крякать, летать и плавать.

Хватит слов, давайте поиграем в утиного бога

Итак, создадим нашу утку (хранилище состояний).

Если вы ранее использовали redux, то вы привыкли, что у вас есть одно хранилище состояний для всего приложения. Напротив, Biscuit-store поощряет создание нескольких контейнеров для разных абстрактных сегментов вашего приложения.

import { createStore } from '@biscuit-store/core';export const { store, actions } = createStore({  name: 'duck',  initial: { value: '' },});

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

Теперь мы должны донести до нее, что она утка и должна делать вещи, присущие уткам.

import { createStore } from '@biscuit-store/core';import { adapter } from './adapter';export const { store, actions } = createStore({  name: 'duck',  initial: { value: '' },  actions: {    duckSwim: 'duck/swim',    duckFly: 'duck/fly',    duckQuack: 'duck/quack',  },  middleware: [adapter]});

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

import { createAdapter } from '@biscuit-store/adapter';const { action, connect } = createAdapter();action('duck/swim', () => {    return { value: 'duck flews' };});action('duck/fly', () => {    return { value: 'duck flews' };});action('duck/quack', (payload, state, { send }) => {    // This is an asynchronous way of transmitting the payload    send({ value: 'duck quacks' });});export const adapter = connect;

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

Наша утка готова отправится в большой мир.

Давайте проверим, на что она способна.

import { actions, store } from './store/duck'const { duckQuack } = actions;store.subscribe((state) => {    console.log(state.value); // 'duck quacks'})duckQuack.dispatch();

А так это будет выглядит в React.

import { observer, useDispatch } from '@biscuit-store/react';import { actions } from './store/duck';const { duckQuack } = actions;export default observer(  ({ value }) => {    const [setQuack] = useDispatch(duckQuack);    return (      <div className='DuckWrapper'>        <p>action: {value}</p>        <button onClick={setQuack}>Duck quacks</button>      </div>    );  },  [duckQuack]);

Вот небольшое демо.

На этом все, спасибо за внимание!

Web-сайт проекта

Biscuit-store молод и нуждается в поддержке

Biscuit еще очень молод и находится в стадии бета-тестирования.
Если вам понравилась эта библиотека, помогите ей развиваться звездочкой в GitHub'

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

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

Начинаем с малого: ты, да я, да мы с тобой

Мы не собирались строить все из ничего, сходу создавая сложную структуру саппорта. Начали с малого в апреле 2020 года. Тогда мы пригласили тимлида и попросили его найти коллегу-инженера. Вместе они занимались решением технических вопросов, которые нужно было решать партнерам и клиентам. Чуть подробнее о том какие вопросы решались - ниже, в подразделе Диверсификация обязанностей. Ни о какой круглосуточной работе изначально не было и речи, это была стандартная пятидневка и график с 9:00 до 18:00.

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

Суббота и воскресенье? Работаем!

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

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

Подсчитали, сколько еще людей нужно добрать, прокалькулировали связанные с расширением операционные расходы, посмотрели статистику звонков. Как оказалось, основной трафик идет по будням с 10:00 до 20:30, так что смысла оплачивать дополнительные 14 часов в день пока не было. Но вот субботу и воскресенье решили добавить.

Решение нашли быстро: недельный дежурный с дополнительной оплатой по выходным.

А теперь - диверсификация обязанностей

Компания росла, расширялся и отдел поддержки. Не очень быстро - к октябрю 2020 года количество сотрудников в нем достигло 6 человек. Это 1 тимлид и 5 инженеров.

Клиенты и партнеры саппортом были вполне довольны. Но задач, конечно, стало больше, увеличилось и их разнообразие. С течением времени мы стали замечать, что отдел сам по себе разделился на две части, как раз по типам решаемых задач. Условно это было разделение на "Help Desk" и на "мониторинг". Работа стала эффективнее, и мы уже официально разделили отдел на два подразделения:

• Help Desk - 2 человека

• Мониторинг - 3 человека

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

Задачи Help Desk:

• Поддержка платформы и локализация ее проблем (ошибки API; кнопка работает не так, как должна; нет доступа и тд.).

• Поддержка сервисов платформы и локализация проблем с ними (робот не звонит, вместо "привет" распознает "вечер, море, хочу в отпуск", тарабанит фразы как робот и становится не похож на человека).

• Поддержка SIP-телефонии (сетевые проблемы телефонии).

• Поддержка External API.

Задачи мониторинга:

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

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

Спустя некоторое время оценили преимущества разделения:

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

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

3. Задачи выстроились в стройную систему.

4. Выходные можно закрывать без дежурного.

Последний пункт стоит немного пояснить. Дело в том, что на этом этапе мы отказались от дежурного в подразделении Help Desk. Вместо этого мы предложили подразделению мониторинга 7-часовой рабочий день по будням с тем, чтобы на выходные у сотрудников оставалось 10 дополнительных часов. Это решение обсуждалось вместе с сотрудниками, которые были не против. Схема простая: сначала один человек работает по 7 часов по будням и в выходные, потом второй, потом третий и так далее. Ну а затем - наша песня хороша, начинай сначала.

Ну привет, круглосуточная поддержка

Выше уже упоминалось, что круглосуточную поддержку мы не вводили, поскольку подавляющее большинство клиентов и партнеров обращались с вопросами в обычное время - с 10:00 до 20:30. Почему так? Все просто - те, с кем мы работали ранее, находились в одном с нами часовом поясе.

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

Сначала получалось так:

1. Help Desk - c 9:00 до 18:00 по будням. Здесь пока что ничего не менялось.

2. Мониторинг - 3 смены: 9:00-18:00 (2 человека), 14:00-21:00 (1 человек), 1:00-9:00 (1 человек, добрали позже из другого часового пояса на ГПХ).

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

Изначально выбирали из трех перспективных вариантов реализации полноценного круглосуточного саппорта:

1. Три смены по 9 часов - утро, вечер, ночь.

2. 2/2 по 12 часов

3. Сутки через трое (Why not? как гипотеза подойдет)

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

1. Желание сохранить команду (многим не нравится сменный график, и в этом нельзя никого винить)

2. Необходимость сделать оплату смен достойной (текучка кадров никому не нужна)

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

4. Поиск сотрудников.

Поразмыслив, мы решили оставить первый вариант - три смены по 9 часов. Почему так? Режим сутки через трое рассматривался просто как экзотичный вариант. Но работать 24 часа, а потом трое суток быть дома - на это соглашаются далеко не все, и это понятно. Суточные смены очень сложные.

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

Что было сразу, до глобального перехода на круглосуточную работу?

1. Help Desk - 4 инженера.

2. Мониторинг - 3 инженера + 1 инженер ночью.

Теперь решаем наши задачи:

Сохраняем команду - оставляем у всех все так, как есть сейчас. Пусть продолжают работу по стандартному графику - 9:00-18:00

Рассчитываем минимальное количество людей на смене - тут все зависит от нагрузки и трафика в вечер и ночь. В нашем случае достаточно по 1 человеку на ночную смену для каждого подразделения:

Итого нужно:

1. Help Desk - 4 утро, 1 вечер, 1 ночь.

2. Мониторинг - 3 утро, 1 вечер, 1 ночь.

После решения этой задачи приступаем уже к реализации. Набрасываем график с 18-20 обязательными сменами (естественно, его можно варьировать), чтобы был запас на больничные/отпуска и ребята могли добрать смен вплоть до 25+.

Где мы искали дополнительных сотрудников для вечерних и ночных смен? Да где и все, собственно - HH, Rabota, LinkedIn и др. Кстати, были даже попытки найти разработчиков на Tinder, но об этом уже в другой раз.

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

Всем привет.

Я team lead, сертифицированный коуч и начинающий психолог.

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

Я работал в двух продуктовых компаниях, одной outstaff (жил и работал в Абу Даби, по контракту с минской компанией) и двух outsource. В общей сложности был где-то на 15 проектах.

В этой статье хочу поделиться своим видением текущей ситуации на рынке.

• За время работы заметил следующие интересные феномены:

• В продуктовых компаниях люди чаще обсуждают что изменить в продукте (язык заплетается). В outsource компаниях в процессах

• В продуктовых компаниях меньше менеджмента

• В продуктовых компаниях реже взаимодействие с заказчиком (или целевой аудиторией)

Ни на одном проекте не встретил аналитику в outsource.

Здесь думаю следует пояснить, что такое outsource.

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

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

Здесь очень важно понимать, что заказчик в момент обращения за помощью уже находится в НЕ спокойном состоянии. Его напряжение настолько сильное, что он готов расстаться со своими деньгами, лишь бы его избавили от этого напряжения. Более того, он согласен принимать условия scrum, agile и прочего, лишь бы только не встречаться снова с проблемой, которую он не хочет решать.

Забегая вперёд, именно от незнания вышеизложенного часто идёт удивление почему заказчик вдруг стал недоволен. Он и был недоволен, и это вообще не с вами связано.

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

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

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

Таким специалистам необходимо иметь достаточно неплохие дипломатические навыки. И чётко разделять профессиональную и личную критику (вы делаете фигню и вы козёл).

Заказчик, каким бы он милым не казался, будет находиться в большом стрессе. И его логичным желанием будет слить своё напряжение в дипломата со стороны outsource.
Таким специалистом не должен быть разработчик (либо это должно быть отдельно прояснено с ним).

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

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

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

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

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

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

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

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

И здесь есть интересная ловушка.

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

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

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

Для упрощения воспользуемся метафорой семьи.

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

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

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

Здесь очень важно заметить про страх непринятия и обесценивания.

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

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

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

Получается при сильной фигуре заказчика, старшие разработчики могут открыто выражать своё недовольство как менеджерам, так и заказчикам. И уже отстаивать свой личный интерес.
Младшие же разработчики так делать не могут (чаще всего) в силу собственной идентичности в данной группе.

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

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

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

В такой ситуации для менеджеров наступает момент встречи с "ребёнком в подростковом периоде". Когда он ещё не самостоятельный (человек всё-таки на контракте). Но уже требует своего признания (уважение его договоров с заказчиком).

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

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

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

Такой конфликт спор за признание родителя. Или "про процессы". Является наиболее частым в outsource компании именно из-за специфики работы.

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

От сюда и появляется первый феномен (из начала статьи).

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

А как следствие там будет скорее конфликт между детьми в коллективе в стиле папа, посмотри, как я могу (больше разговоров про непосредственно работу), чем про процесс. Никто не будет хотеть бороться за место отца, все будут бороться за его внимание друг с другом.

Как следствие разворачивается и второй пункт меньше менеджмента. Он практически не нужен. Всё прекрасно работает.

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

Про аналитику просто наблюдение. Ни с чем не смог связать.

Я системный администратор, более 20 лет занимаюсь управлением и мониторингом критичной в масштабах страны инфраструктуры. Услуги, которые я администрирую, предоставляются по модели SaaS (Software as a Service аренда ПО). Это моя первая публикация, я решил поделиться своими наработками в этой области, возможно кому-то это будет полезно.

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

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

История

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

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

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

Я решил учесть ошибки и разработать новую систему. Большинство продуктов создаются разработчиками ПО, а я системный администратор. Я хуже знаю процесс разработки, но проектирование и реализация системы для системных администраторов в данном случае сделана системным администратором, с учетом нюансов нашей работы. Считаю, что это положительно сказалось на конечном результате

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

ALEPIZ

Новая система получила название ALEPIZ. Я не планировал ее распространять, но создание системы затянулось. Чтобы не платить за средства разработки я выполнил условия для их бесплатного использования: выложил ПО на GitHub под лицензией GPL v3 и создал сайт alepiz.com.

Архитектура системы

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

Тестирование и эксплуатация ведется под ОС Microsoft Windows. Выбор ОС продиктован архитектурой программного обеспечения, которое используется в моей организации.

Для возможности портирования в будущем на другие архитектуры, в качестве платформы были выбраны JavaScript и NodeJS. Это так же позволило унифицировать разработку backend и frontend и использовать асинхронность JavaScript для достижения требуемой производительности. Применение потоков (threads) в NodeJS невозможно из-за отсутствия поддержки во многих модулях, поэтому используется схема с запуском нескольких процессов.

В ALEPIZ встроен Web сервер и сервер БД на основе быстрой и простой SQLITE. При развертывании системы нет необходимости в установке дополнительного ПО: ALEPIZ включает все требуемые компоненты. Для ускорения работы с БД реализована система кэширования, разработанная специально для ALEPIZ.

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

Сейчас ALEPIZ обслуживает одновременно более 250 000 метрик. Их количество постоянно увеличивается. Сбор данных по метрике происходит примерно раз в 3060 секунд. Исторические данные хранятся три месяца и база данных занимает около 1Тб. Для работы используется сервер с двумя процессорами Intel, по двенадцать ядер в каждом. Суммарная загрузка процессоров около 40% и зависит от количества расчетов, выполняемых ALEPIZ. Потребление памяти 64Gb. В качестве дисковой подсистемы используется RAID10 из 8 HDD 10 000 Rpms. Репликация и резервное копирование БД производится по сети на другой сервер.

Системные требования

Для работы ALEPIZ требуется компьютер архитектуры Intel x64 с установленной ОС Microsoft Windows версии не ниже Windows Server 2012 или Windows 10. После установки ALEPIZ использует 200Mb дискового пространства. Потребление оперативной памяти на сервере с 12 ядрами CPU составляет 1Gb. При меньшем количестве ядер потребление памяти будет уменьшено.

Описание возможностей

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

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

ALEPIZ является не только системой мониторинга, но и системой для управления инфраструктурой. Для этого существуют специальные модули - действия. Например, действием может быть запуск или остановка внешнего сервиса, редактирование файла настроек, выполнения запросов к БД или копирование файлов для обновления ПО. Можно разрабатывать собственные действия.

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

Описание возможностей системы есть на сайте ALEPIZ и доступно на русском языке.

Сущности системы

Чтобы получить больше информации о принципах работы системы и ее возможностях, немного погрузимся в ALEPIZ.

Коллекторы

Для сбора данных используются модули, которые называются коллекторами (collectors). Например, коллектор PING используется для проверки доступности хостов по протоколу ICMP. Коллектор SNMP необходим для сбора данных по одноименному протоколу. MSSQL служит для выполнения запросов к БД MSSQL и т.п. На момент написания статьи в ALEPIZ реализован 21 коллектор. Можно разработать собственный. Информация о разработке коллектора и средства для разработки встроены в ALEPIZ.

Каунтеры

Каунтеры (counters) это коллекторы с параметрами, которые определяют, какие данные необходимо собирать. Например, для того чтобы коллектор PING начал собирать информацию, ему в качестве параметра необходимо передать имя хоста, доступность которого требуется проверять. Параметры для коллекторов настраиваются в каунтерах.

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

Активные и пассивные коллекторы. Зависимости в каунтерах

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

Например, каунтер с активным коллектором Timer генерирует данные через определенные интервалы времени. Если от него сделать зависимым каунтер с пассивным коллектором SNMP, то данные по протоколу SNMP будут собираться через определенные каунтером интервалы времени. Если от каунтера с SNMP сделать зависимым каунтер с коллектором Events generator, то в случае превышения установленного порогового значения, в Dashboard появится предупреждение о возможной проблеме.

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

Объекты

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

Связь объектов и каунтеров

Каунтеры не могут существовать сами по себе. Каждый каунтер должен быть привязан к одному или нескольким объектам. У объектов можно настроить свойства, которые будут использовать каунтеры для сбора или генерации информации. Например, объект хост может содержать свойство IP адрес, который будет использован каунтером с коллектором PING для проверки доступности этого хоста. Каунтер с коллектором PING можно привязать к нескольким объектам- хостам и он будет собирать данные в зависимости от настроенных свойств (IP адреса) для каждого из объектов.

Действия

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

Можно разработать собственные действия. Информация и средства для разработки встроены в ALEPIZ.

Задачи

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

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

Остальные возможности

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

Заключение

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

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

Хотел бы еще раз повторить: ALEPIZ распространяется бесплатно по лицензии GPL v3. Вы можете использовать его на свое усмотрение. Я не знаю способов монетизации системы, поэтому принял решение сделать его доступным для всех.

Если Вы решили поставить систему у себя, проще всего скачать и запустить установочный пакет для ОС Microsoft Windows со страницы https://alepiz.com/help/download.pug. В этом случае установка и первичная настройка системы произойдет автоматически. ALEPIZ можно поставить даже на персональный компьютер или ноутбук под управлением Windows 10.

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

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

Спасибо за прочтение, надеюсь, ALEPIZ поможет Вам и Вашему бизнесу в достижении новых целей.

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

Красота в наших глазах. Но руководитель часто далек от технических деталей. Часто очень сложно объяснить всю программистскую кухню на языке диаграмм Ганта. Когда штудирование документации и вычитывание кода библиотеки выливается в метрику +10 строк кода. (За половину месяца.) Ну ведь правда, как-то не солидно 0.125 строк кода в день. (Это сколько символов в день? А в час?) Правда?

Мы правда должны опускаться до уровня руководителей?

И дело даже не в разных решаемых задачах. О том, что и мы программисты, и менеджеры, и маркетологи решают одну задачу создание успешного продукта/услуги. Каждый на своём месте движемся к реализации общей задачи. В роли лидеров или работников, как эксперты, или как испытатели, исследователи, тестировщики, технические писатели и т.д.

Но все же, что же с диалогом?

Если задаться вопросом: а нужно ли пасовать?

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

А если о диалоге?

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

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

Кейс разработки.
Разработчик завис над простой задачей. Занимался задачей две недели. По результатам двух недель работы внес в репозиторий изменений на 10-20 строк кода. В отчете по задаче множество технических деталей. В отчете выставил необходимость дополнительного времени на доработку задачи.

Если для вас кейс очевиден, то можно дальше и не читать.

Список проблем.

Перерасход бюджета. Разработчик потратил уйму времени на простую фичу и требует дополнительное время.

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

Возможность конфликта с разработчиком.

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

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

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

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

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

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

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

И так далее. (Прописываю только часть проблем.)

Решения.

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

Спасибо.

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

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

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

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

Немного истории

Компания PVS-Studio имеет более чем десятилетнюю историю развития. Все это время работы ведутся над одноименным статическим анализатором кода. Подробнее про это можно почитать в статье "Как 10 лет назад начинался проект PVS-Studio". Таким образом, PVS-Studio фактически компания одного проекта. И это проект для разработчиков. Но мы внутри компании в качестве проектов привыкли также выделять и другие направления работы, которые фиксируются в трекере задач наравне с разработкой: маркетинг, продажи, внутренние интернет-проекты, административная и IT-поддержка офиса. Все это создает достаточно большой поток разнородных задач, с которым нужно как-то справляться.

До перехода на новый трекер мы использовали Bitbucket. Первая задача там датирована 30 июня 2014, а последняя 5 февраля 2021 (примерно с этого момента мы начали использовать новый инструмент, про это будет вторая часть статьи). Всего за это время было создано 5527 задач. До Bitbucket в компании использовали еще какой-то инструмент, но не будем забираться так далеко в прошлое. Примерный подсчет дает около 3.3 новых задач на один рабочий день (при условии 250 рабочих дней в году и 24 рабочих дней в месяце). Давайте округлим это число до целого, не забыв, что не все задачи были доведены до состояния "Решено". Итого мы получим три новых задачи в день на примерно 30 сотрудников компании (с 2014 по 2021 год размер компании увеличился вдвое: с 20 до 40 человек). Вероятно, можно считать, что также и закрывали примерно три задачи в день. Предлагаю не анализировать это число, так как оно ничего не говорит о числе задач, находящихся у сотрудника единовременно в работе. Вот такой показатель был бы нам полезен. Но, к сожалению, получить его можно только экспериментально и при работе с определенной методологией, о чём будет рассказано далее.

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

Несмотря на то, что в нашем случае развитие компании шло достаточно планомерно, мы, как и многие другие, столкнулись с типичным паттерном проблемы: "Еще год назад это работало (хватало), а теперь не работает (не хватает)". Здесь и площадь офиса, и число баночек газировки в холодильнике, и максимум доступных процессорных потоков на сборочном сервере, и пр. Такая же ситуация с организацией работы и управлением. Кажется, еще совсем недавно мы обходились без регулярных one-to-one. Повышение разработчика происходило по принципу "вроде норм кодит". А фраза "верни задачу в бэклог на kanban" могла быть расценена в лучшем случае как неумелый троллинг. Конечно, все это обычная ситуация роста, и говорить о большой проблеме тут излишне сгущать краски. Тем не менее, на мой взгляд, от готовности команды и руководства компании к переменам в таких ситуациях зависит успех бизнеса.

С какими же конкретно проблемами мы столкнулись при увеличении размера компании и росте потока задач? Основная сильная централизация управления процессом разработки. К концу 2019 года вся разработка в компании на всех уровнях контролировалась в основном техническим директором, а в командах не хватало тимлидов. Также не вполне понятен был жизненный цикл задачи, неполно отслеживалась эффективность работы и сложно прогнозировался ее результат. В штате PVS-Studio на тот момент состояло около 34 человек: команды маркетинга и продаж; команды разработки на языках C/С++, C#, Java; команда DevOps, административный персонал и руководство. Примерно половина команды занималась непосредственно разработкой.

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

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

Выбор методологии

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

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

• простота перехода. Мы предвидели возможность естественного сопротивления команды, поэтому хотелось внедрить новые практики максимально безболезненно для рядовых сотрудников;

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

• возможность сопровождения своими силами, несложная в освоении методология;

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

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

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

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

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

На самом деле, многое из того, что декларирует agile, мы применяли ранее. Мы проводили ежедневные митинги, хоть и не во всех командах. Команды, как я уже говорил, были достаточно самоорганизованы, а сотрудники отвечали за результат. Также сотрудники имели некоторую свободу при выборе задач, например могли заняться написанием статьи одновременно с процессом разработки, самостоятельно планируя своё рабочее время. Любой сотрудник мог поставить задачу другому, независимо от его уровня в компании (матричная структура). Наконец, у нас были подобия спринтов, привязанные к релизному циклу.

Не хватало только систематизации, ритмичности при работе с потоком задач, а также чётко прописанных правил и требований, которые бы были понятны, однозначно приняты и соблюдались каждым участником процесса. "Баланс и общение" вот практически девиз нашей команды в настоящее время. И kanban здесь подходит как нельзя лучше.

Подпольный kanban

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

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

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

• по столбцам в первоначальном варианте получилось так: Backlog (общий пул задач), Assignee (ответственный, исполнитель), On hold (буфер задач исполнителя), Analyze (задача на стадии изучения), In progress (задача в работе), Check (оценка результатов, приёмка), Done (задача решена);

• макет карточки выглядел так:

• некоторое время потратили на выбор значения лимита незавершенной работы (WIP) для исполнителя. Логичным казалось, что у человека не может быть в работе одновременно более двух задач. Тем не менее, для начала решили остановиться на ограничении в три задачи, учитывая, что разработчики у нас могут заниматься и не связанными с разработкой активностями (написание статей, например), которые можно эффективно совмещать с разработкой. Для kanban такой подход является классическим: вначале выбирается примерное значение, которое затем уточняется в процессе работы. Вообще весь kanban это один сплошной эксперимент в попытке уменьшить значение WIP. :) Спойлер: значение WIP мы в итоге все же установили равное двум;

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

• за следующие пару недель использования макет доски ещё несколько раз уточнялся. Добавили отдельную строку для задач-эпиков без конкретного исполнителя. Уменьшили ширину столбца "Done" и за счет этого увеличили ширину столбца для бэклога. Добавили столбец "Waiting" (задача на ожидании, например, ответа от клиента, или статья на переводе) между столбцами "Check" и "Done". Решили использовать карточки разных цветов для разделения задач по типу работ: просто задача, правка бага, эпик, написание статьи и т.п.;

• любая правка доски обсуждалась, при этом обсуждения часто бывали достаточно эмоциональными;

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

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

Так прошло чуть больше месяца (с учетом новогодних каникул), и вот в январе 2020 года мы, наконец, решили, что пришло время обнародовать доску (на фотографии ниже видна одна сторона доски, не включающая направление C++).

Kanban в массы

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

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

Итак, наша доска с актуальными задачами была представлена на всеобщее обозрение и размещена в конференц-зале. Ранее мы уже практиковали ежедневные рабочие собрания, но они не носили системный характер и проводились от случая к случаю. Теперь мы решили организовать работу по расписанию и проводить ежедневные митинги по отдельности для четырёх команд разработки (C/С++, C#, Java; DevOps). Продолжительность митинга установили не более 15 минут. В дополнение к этому в отделе маркетинга велась еще одна независимая доска, которая несколько отличалась, но также вписывалась в нашу общую концепцию работы по kanban.

Собственно, введение ежедневных митингов по расписанию, а не доска, стало причиной ожидаемого сопротивления команды. Основной вопрос был примерно такой: "Зачем нам эти митинги? Мы и так знаем, кто и что делает внутри команды, проводим свои ежедневные обсуждения. Просто трата времени какая-то. Да еще эта доска". Нам кажется, что теперь после более чем года работы по kanban мы можем дать ответы на эти и другие вопросы.

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

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

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

Таков путь

К сожалению, полноценно поработать с физической kanban-доской нам удалось только два релизных цикла (четыре месяца). После чего весной 2020 года весь офис, в связи с известными событиями (COVID), был переведен на удалённый режим работы. Конечно, ведение доски в таких условиях оказалось невозможным, и, что характерно, мы остро почувствовали нехватку этого инструмента при проведении ежедневных митингов. Я думаю, это основной показатель полезности любого инструмента: когда ты начинаешь ощущать дискомфорт при его отсутствии.

Примерно в это время мы начали задумываться об электронной kanban-доске. Какое-то время ситуация с COVID была непонятной, мы вели онлайн-митинги в Zoom. При этом каждый участник использовал список задач Bitbucket, чтобы отчитаться о работе. Это было очень неудобно и осложняло и так непростой режим работы online.

Осенью 2020 года стало понятно, что удаленная работа затягивается. Возникла идея не просто внедрить электронный аналог kanban-доски, а действовать более радикально и полностью сменить трекер задач на более удовлетворяющий нашим требованиям на тот момент. В первую очередь, конечно, мы обратили внимание на Jira. Тем более что переход на эту систему с Bitbucket позволил бы легко перенести все ранее созданные задачи. Также мы рассматривали еще одну систему YouTrack, которая очень нравилась тимлиду нашей С++ команды (привет, Филипп). Более того, по этой системе еще летом Филипп даже делал презентацию для менеджеров.

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

Заключение

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

Что касается вообще методологий agile и kanban, их ценности для построения рабочих процессов, сложности внедрения, могу еще раз кратко озвучить наш опыт. Главное не бойтесь экспериментировать. Ведь не зря же эти подходы называют гибкими. Я бы еще добавил, что они достаточно дружелюбны и прощают множество ошибок. Можно внедрить новые подходы максимально безболезненно и даже скрытно на первых порах, а в случае неудач потери будут невелики. И если вы, как в нашем случае, будете внедрять какую-то методологию с нуля, то полученный результат, польза, точно превысят затраты.

Спасибо за внимание и до встречи во второй части.

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Sergey Khrenov. PVS-Studio Team's Kanban Board. Part 1: Agile.

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

Кто такие Valve?

Valve Corporation американская компания-разработчик компьютерных игр. Автор хитов Conter-Strike, Left for Dead, Dota 2, создатель магазина игр Steam и очков виртуальной реальности Steam Index. Основана в 1996 году бывшими сотрудниками Microsoft Гэйбом Ньюэллом и Майком Харрингтоном.

В 2017 Forbes подсчитал, что основатель Valve Гэйб Ньюэлл с состоянием в $4,1 млрд. обогнал самого Дональда Трампа с его $3,7 млрд. При этом основной доход Ньюэлла составляет прибыль от магазина игр Steam, в том числе от покупок геймеров в Dota 2 и Counter Strike: Global Offensive.

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

Иерархия идеальна для стабильных и предсказуемых результатов, именно поэтому она так активно применяется в армии. Но если вы работаете в сфере развлечений и привлекаете самых одаренных людей на планете, то усадив их за стол и сказав делать, что велено, вы даром растратите 99% их ценности, убеждены в Valve.

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

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

О том, что клиент всегда прав, вам скажут в любой компании, но только у нас это утверждение подтверждается практикой.

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

Принцип 2. Выбери проект по душе или придумай свой

В компаниях типа Google сотрудникам дают право посвящать до 10% времени личным проектам. В компании Valve этот процент равен 100.

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

• В каком из проектов я буду наиболее полезен?

• Какой проект больше влияет на потребителей?

• От работы над какими задачами я получу удовольствие?

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

Принцип 3. У столов должны быть колесики

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

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

Принцип 4. Право на ошибку

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

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

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

Принцип 5. Обратная связь всему голова

Как устроен карьерный рост в Valve? Как повышать кому-то зарплату в компании, где все равны?

В Valve существует два официальных способа оценки друг друга: рецензирование и ранжирование.

Рецензирование это сбор отзывов о совместной работе. Группа людей, состав которой регулярно меняется, проводит опрос: с кем каждый сотрудник работал в последнее время и каковы впечатления от совместной работы. Отзывы обрабатываются и передаются анонимно.

Ранжирование и оплата труда

Прибыль компании в пересчете на сотрудника превышает аналогичные показатели Google, Amazon и Microsoft. В связи с этим Valve считает справедливым платить своим людям выше рынка.

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

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

1. Профессиональный уровень/технические навыки

2. Продуктивность/результативность работы

3. Роль в команде

4. Вклад в разработку продукта

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

Принцип 6. Баланс работы и отдыха

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

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

Принцип 7. Поиск сотрудников важнее, чем воздух

Мы ищем людей, которые лучше нас.

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

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

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

• Хотел бы я, чтобы этот человек был моим начальником?

• Многому ли он меня научит?

• Что будет, если этот человек начнет работать у наших конкурентов?

Принцип 8. Ищите Т-образных людей

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

Такой набор качеств ключевой фактор успеха в Valve: узконаправленный специалист плохо взаимодействует с другими сотрудниками. А работник-универсал, не разбирающийся глубоко в определённой области, практически не участвует в работе и как сотрудник едва полезен.

Принцип 9. Самофинансирование

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

Все права на интеллектуальную собственность также принадлежат Valve.

Valve это самофинансируемая компания. Ничто не мешает нам принимать собственные решения в отношении наших продуктов.

Слабые стороны Valve

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

• Помощь новичкам в работе и наставничество

• Распространение информации в компании

• Поиск и прием на работу специалистов в совершенно новых сферах

• Прогнозирование на период более 3-4 месяцев

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

Вопросы за кадром

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

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

На сайте по поиску работу Indeed всего три отзыва о Valve, и все они неплохие, средний бал 4,3:

Источники:

1. Официальный сайт Valve

2. Руководство для новых сотрудников на русском и на английском

3. Статья в Нью-Йорк Таймс

4. Статья по мотивам твитов об ужасах "самоорганизующихся компаний" бывшего сотрудника

5. Страничка Indeed с отзывами на Valve

Для тех, кто предпочитает короткий жанр, автор ведет телеграм-канал@annakopyrneva, где пишет о софтскиллах, продукте и своей работе в ИТ.

В своей преподавательской практике использую GitHub...

Но для начала давайте представлюсь. Зовут меня Старинин Андрей. И я преподаю программирование, хотя по первому образованию я биолог. А ещё один из основателей и ведущих подкаста "IT за Edu".

Мой стек дисциплин:

• C++

  • основы программирования

  • основы ООП

  • GUI-приложения (Qt)

• C#

  • ООП

  • сетевое программирование

  • GUI-приложения (WPF)

  • взаимодействие приложений и БД (ADO.Net)

• Базы данных

  • проектирование БД

  • SQLite

  • MySQL

• Управление проектами

Кажется, что всего много. Но успеваем не сильно погрузиться в отдельные технологии. После какого-то времени (точно не помню уже какого) понял, что студентов можно и даже нужно "приучать" к системам управления версиями почти сразу с начала обучения. Для обучения выбрал GitHub. Хотя Bitbucket тоже нравится. Да, я не учу студентов сразу по харду, они не сразу изучают git в CLI. Я их знакомлю сначала с web-интерфейсом GitHub'а. Потом рассказываю про GUI-клиенты. Из них мне нравится GitKraken. Но не заставляю их пользоваться тем, что нравится мне - они вольны выбирать сами чем пользоваться.

Постепенно - это примерно так:

1. Просто показываю как выкладывать код

2. Прошу их выкладывать свои решения и присылать мне ссылки на репозитории

3. Выкладываю текст заданий и прошу ответы присылать через pull-request'ы

4. Пробуем поработать в маленьких командах над одним репозиторием без веток

5. Пробуем поработать небольшой командой над одним репозиторием с отдельными ветками

6. Пробуем работать над большим проектом большой командой с несколькими репозиториями и ветками.

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

Не все студенты сразу всё понимают и принимают. Но тем интереснее и приятнее когда они "доходят". Ещё люблю подход: учимся на своих ошибках. Во время обучения есть возможность ошибаться и понять к чему это приводит.

Что мне нравится в GitHub при обучении?

• Поддержка аккаунтов для организаций, а в аккаунтах возможность создания команд с гибкими настройками доступов

• Поддержка Markdown-разметки. Можно более "красиво" оформлять задания.

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

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

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

• Система issues. Можно давать другим командам студентов задание на проверку кода и выявления багов, с занесением всего в issues.

Для чего я приучаю студентов к GitHub'у?

• Создание своего портфолио уже с самого начала обучения, а не только под конец.

• Понимание принципов написания кода. Когда начинают чужой код проверять - многое понимают

• Понимание "соглашения об именовании". Пока не наступят на грабли разного именования в одной команде - не понимают. Ну или не все понимают

• Понимание как работать в команде. И как командам между собой взаимодействовать.

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

Управлять проектами машинного обучения (Machine learning) и data science сложно, поскольку проекты часто носят исследовательский характер, и трудно предсказать, сколько времени потребуется на их завершение. Часто всё начинается с одной идеи, а затем перетекает в новое направление, когда предложенный метод не срабатывает или если предположения относительно данных оказываются неверными.

Построение модели также является длительным процессом (по сравнению с работой в сфере программного обеспечения и аналитики), и data scientist нередко попадает в кроличью нору и тратит месяцы на проект, не имея четких представлений о прогрессе. Еще одно отличие от стандартных практик разработки программного обеспечения заключается в том, что построение модели обычно выполняется всего одним человеком, и это не совсем вписывается в традиционные командные рабочие процессы, такие как Kanban и Scrum.

Я потратил достаточно много времени, изучая существующие рабочие процессы (в основном в Jira) с точки зрения пригодности для управления проектами машинного обучения и data science, но безуспешно. Большая часть информации нацелена на разработку программного обеспечения и фокусируется на Agile методологиях. Обсуждая этот вопрос с коллегами и друзьями мне не удалось найти ничего, что было бы адаптировано для машинного обучения и data science. Я заметил, что часть коллег пытаются адаптировать свой рабочий процесс к стандартной инженерной практике, в других же случаях, они вообще не пытаются управлять проектами. Последнее особенно проблематично, по причине того, что проекты, которые требуют слишком много времени и замахиваются на слишком большую предметную область, вероятнее всего провалятся.

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

Этапы проекта машинного обучения четко определены

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

1) Исследование (Research)

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

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

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

План также демонстрируется стейкхолдерам для получения их фидбека.

2) Исследование данных (Data Exploration)

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

Конечный результат: подробный отчет об исследовании данных с помощью Jupiter notebook, содержащий графики и комментарии, дающий какое-либо представление о используемых данных. Отчет будет передан остальной части команды и стейкхолдерам проекта.

3) Моделирование (Modeling)

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

Конечные результаты: Результатами этого этапа являются:

1. Прототип модели

2. Отчет в Jupyter notebook с обширной оценкой модели

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

4) Коммерческое внедрение (Productization)

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

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

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

5) A/B-тестирование (A/B Testing)

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

6) Анализ результатов (Results Analysis)

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

Конечные результаты:

1. Подробный отчет о результатах в Jupyter notebook.

2. Гипотеза относительно того, почему все пошло не так, как ожидалось (если это возможно)

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

Работа с Jira

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

На самом деле это довольно просто. Мы используем доску Kanban в Jira и горизонтальные колонки (swimlanes, по одной на члена команды) с несколькими кастомными полями и изменениями. Приведенные ниже рекомендации определяют суть этого процесса:

• Для каждого проекта создается новый эпик (Epic) тикет, а работа разделяется на задачи (Tasks).

• Каждая задача помечается этапом (Phase) - кастомным полем в Jira для выбора одного из 6 этапов, перечисленных выше. (Обратите внимание, что на одном этапе может быть несколько задач.)

• Задачи не могут длиться больше 1 недели (5 дней). Это заставляет членов команды разбивать свою работу на более мелкие (но все же довольно значительные) части, что позволяет отслеживать прогресс с минимальными накладными расходами.

• Одновременно в работе может быть только один тикет. Это гарантирует то, что мы всегда видим статус проекта.

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

Заключение

Управление проектами машинного обучения и data science не должно быть сложным. Сначала я тратил порядка 30 минут в день на мониторинг этого процесса, но как только команда привыкла к нему, мое время сократилось до 15 минут в неделю! Я знаю, на каком этапе находится каждый проект в любой момент времени, сколько времени он занял, и я могу быстро выявить проблемы, чтобы при необходимости вмешаться и помочь своей команде. Мои data scientistы имеют четкую схему работы для построения модели, и они стали в этом намного эффективнее.

Я надеюсь, что все это окажется таким же полезным для Вас, как и для меня.

Перевод статьи подготовлен в преддверии старта курса "Промышленный ML на больших данных".

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