Русский
Русский
English
Статистика
Реклама

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

Сам сломаю, сам и починю как я эпически нажал не туда на проде

14.04.2021 10:21:24 | Автор: admin
Привет, Хабр!

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

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

Начинается история так: заказчик хочет перенести на эту группу коммутаторов ядро всей сети. Такое решение обусловлено тем, что архитектура ACI, в которую собрана эта группа коммутаторов очень отказоустойчивая. Хотя это не типично и в целом фабрика в любом ЦОД не используется как транзитная сеть для других сетей и служит только для подключения конечной нагрузки (stub network). Но такой подход вполне имеет место быть, поэтому заказчик хочет мы делаем.

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

image

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

По порядку


Запрос заказчика звучал так: нужно было построить отдельные порт-группы под перенос оборудования непосредственно на эту фабрику.
Коллеги, просьба перенести настройки портов Leaf 1-1 101 и leaf 1-2 102, порты 43 и 44, на Leaf 1-3 103 и leaf 1-4 104, порты 43 и 44. К портам 43 и 44 на Leaf 1-1 и 1-2 подключён стек 3650, он пока не введён в эксплуатацию, переносить настройки портов можно в любое время.

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

Проблема в том, что на фабрике настройки этих порт-групп привязаны к отдельной сущности (которая возникает вследствие того, что фабрика управляется с контроллера). Этот объект называется port policy. То есть к группе портов, которые мы добавляем, нужно ещё сверху применить общую политику как сущность, которая будет управлять этими портами.
То есть нужно было сделать анализ, какие EPG используются на портах 43 и 44 на нодах 101 и 102 для того, чтобы собрать аналогичную конфигурацию на нодах 103-104. После анализа необходимых изменений я начал настраивать ноды 103-104. Для настройки нового VPC в существующей политике интерфейсов для нод 103 и 104 нужно было создать политику, в которую будут заведены интерфейсы 43 и 44.

И там есть в GUI один нюанс. Я создал эту политику и понял, что в процессе конфигурирования допустил незначительную ошибку, назвал её не так, как принято у заказчика. Это не критично потому что политика новая и ни на что не влияет. И мне эту политику нужно было удалить, поскольку изменения в неё уже внести нельзя (название не меняется) можно только удалить и заново политику создать.

Проблема в том, что в GUI есть иконки удаления, которые относятся к политикам интерфейса, а есть иконки, которые относятся к политикам коммутатора. Визуально они почти идентичны. И я вместо того, чтобы удалить политику, которую я создал, удалил всю конфигурацию для интерфейсов на коммутаторах 103-104:

image

Вместо удаления одной группы фактически удалил все VPC из настроек ноды, использовал delete вместо trashbin.

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

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

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

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

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

Восстановление фабрики


На восстановление фабрики с учётом всех звонков и сбора всех причастных ушло 30 минут.

Нашли другой VPN, через который можно зайти (это потребовало согласования с безопасниками), и я откатил конфигурацию фабрики в Cisco ACI это делается в два клика. Ничего сложного нет. Просто выбирается точка восстановления. Занимает это 1015 секунд. То есть на само восстановление ушло 15 секунд. Всё остальное время было потрачено на то, чтобы понять, как получить удалённое управление.

image

После инцидента


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

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

Так же мы покопались глубже в ПО Cisco Network Assurance Engine (NAE), где нашли возможность сделать на фабрике ACI две простые, но очень важные вещи:

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

Если интересно больше деталей у нас завтра вебинар про внутреннюю кухню техподдержки, будем рассказывать, как всё устроено у нас и у вендоров. Ошибки тоже будем разбирать)
Подробнее..

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

15.04.2021 18:16:38 | Автор: admin

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

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

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

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

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

Подробнее..

Архитектура архитектуры воспалённый аппендикс

11.04.2021 02:13:35 | Автор: admin

Да, если запустить, то будет больно. Ну а пока, возрадуемся же выигранному конкурсу! Ожидать горы золота или похвалы будет как минимум глупо. Солнце ещё высоко и время работать. Дядюшка Скрудж не выстроил бы своей империи, если б сразу бил по рукам и переходил к оплате. Поэтому его воплощение в вашем энтерпрайз-заказчике в очередной раз просто улыбнётся и опять поправит очки. Это, внучка, чтобы получше тебя видеть. И, конечно, чтоб читать текст приложений к контракту мелким шрифтом. Техническая часть всегда запрятана где-нибудь в Appendix 7/C.1.1

Copy of a written deal by Christoph Haizmann from 1669.Copy of a written deal by Christoph Haizmann from 1669.

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

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

Пятиминутка ненависти и личного опыта

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

Ищите самые большие классы

Места с максимальной цикломатической сложностью

Покрытие юнит тестами

Автоматические тесты интеграции

Ищите триггеры и процедуры в базе данных (особенно если это сиквел)

Вы скажете, а в чём секрет это же стандартные метрики кода! А секрет в том, что почему-то никто их не смотрит! Даже хвалёные аудиторы. Иначе как можно купить IP на монолит без тестов с классами по 10000 строк, switch на 600 кейсов и половину бизнес логики в процедурах. Ненависть! Но стоит понимать, что частая ошибка покупающей стороны в том, что они думают, что покупают продукт. А такового никогда не было. Была команда. Как только эта команда покидает судно, оказывается, что они держали все доски голыми руками и без этих рук это даже не лодка, а просто куски древесины в солёной, от слез покупателя, воде.

Функциональные требования

Начнём с очевидного, но невероятного. Помните на первых этапах подачу иконостаса с тех. стеком? Так вот время его перепроверить на соответствие всем изложенным в задании сценариям. И самое главное - передать ответственным игрокам с вашей стороны список жёстких конструкций. Таких жёстких, что легко ломают не только мозг при осмотре, но и спину при падении. У каждой технологии есть ограничения. Эти границы могут сильно влиять на бизнес. Для отдела продуктового дизайна и для вашего клиента подобные вещи совсем не очевидны. Даже если для вас это настолько тривиально, что и упоминания не стоит. Самым популярным кейсом будет не требование работы в оффлайн с полностью облачным бекэндом. Это на втором месте. На первом конечно же полная согласованность всех данных с постоянной доступностью в распределенной системе. На этом невысказанном предположении зачастую строится очень много критического функционала. Сколько бы раз вы не повторяли мантру Брюера все будут считать это какой-то теоретической лабудой. Мы то не в каменном веке, вот сейчас как сделаем Даже эксперты, которых вам предлагают облачные платформы в 80% (5 из 6 на моём опыте) уверены, что если вы работаете по well-architectured шаблонам, то никаких проблем с согласованностью данных не будет. Это проблемы конкурентов. В нашем облаке такого быть не может!.

Всё что нам необходимо, это чтоб везде, где в контракте есть конкретные технологии, требования и сроки, была приписка мелким шрифтом, что возможны изменения. Типа конкретная технология будет выбрана непосредственно перед/вовремя реализацией или если требование не вступает в конфликт с ограничениями технологий или это или альтернативное решение. Дело в том, что такие вещи просто необходимы ввиду длинного срока разработки. Изменения и дополнения к требованиям неизбежны, и вот именно те, которых еще нет и которые нельзя проверить уже сейчас, станут проблемой. Основной причиной будет выход первых версий в реальную жизнь (через год разработки). Это всегда сюрприз, как зима для коммунальщиков. Я ведь уже упоминал, что тендер пишут люди, которым с продуктом не работать. Так возникает требование использовать приватную криптоэкосистему для аудита финансовых операций. Вполне логично, что если пользователь перевёл деньги, то ни сумма, ни реквизиты измениться не могут и не должны, так что давайте схороним их под грифом хранить вечно c цифровым сургучом. Хайповый блокчейн тут как раз в кейс. Потом продукт попадает на рабочий стол клерка одной маленькой европейской страны, который работает с вашим софтом и, что самое главное, с живыми людьми и деньгами в физическом мире. И тут возникают нюансы. При вкладе наличных он часто ошибается в выборе валюты или записи суммы. Раньше он просто заходил и правил транзакцию на месте, перед тем как выдать квиток клиенту для подписи. Теперь транзакция в реальном времени уходит в сотню точек, а документ закрыт на замок и не принимает правки, да ещё и сам лезит на печать. Если вы всё еще думаете, что только русский язык богат на ругальства, то вам просто не довелось слушать запись звонка почтальона из деревеньки на Корсике в службу поддержи вашего продукта. Ваш клиент хочет просто добавить возможность редактирования, а вы начинаете ему объяснять, что это невозможно. Что нужно поменять подход в привычном бизнес-сценарии вносить корректировочные транзакции, менять отчёты и рапорты. И обновлять внешние системы, которые не знают о существовании нового типа документов, и не являются частью вашего продукта, а просто питаются экспортированными данными для отчётов и всякой аналитики. Ну и вот это вот всё, что работало и копилось годами.

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

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

Нефункциональные требования

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

Appendix HeaderAppendix Header

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

Номер

Требование

Время

1

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

10 минут

2

Максимально допустимое время на синхронизацию клиента

5 минут

3

М.д.в. отклика облачного центра

2 минуты

4

М.д.в время загрузки страницы журнала

1 минута

5

Минимальное время хранения записи в журнале

5 лет

6

М.д.в аутентификации пользователя

1 минута

7

М.д.в авторизации пользователя

1 минута

8

М.д.в перезагрузки системы

3 минуты

9

М.д.в недоступности системы для операций (в месяц)

5 минут

10

М.д.в рассинхронизации данных между клиентом и облаком

5 минут

И всё в таком духе. Абстрактный сценарий и какой-то лимит времени. Тот, кто эти цифры даёт ваш заказчик. Ему не нужно с этим разбираться. Он просто озвучивает желания. Желания всегда ведут к результату лестницей Пенроуза. Так что в начале нужно разобрать всё, ступенькой за ступенькой, и сложить всё в поленницу. А потом упорядочить и структурировать. Что значит структурирование? Построить цепочку зависимостей сценариев в последовательности исполнения. Рассмотрим наш теоретический пример. Сразу скажу, что работать лучше на листе или доске, так как в красивые деревья не вырастут. Будет сложная диаграмма или зацикленные графы. Я вот подобрал удобные сценарии, но всё равно нарисовать в ворде получается, как-то не очень:

Scenario TreeScenario Tree

С подобной диаграммой работать легче, а самое главное намного проще объяснить другим. Надо сразу вписывать недостающие шаги. Допустим процесс логина в таблице отсутствует, но его составляющие есть. Опять-таки, если вокруг вас все специалисты и у вас такой авторитет, что решения объяснять не надо, то можно и пропустить живопись. Вполне ведь себе реальная ситуация, что технический специалист со стороны исполнителя просто говорит: тут вот будет 5 вместо 2 - и заказчик сразу соглашается. Тем же, кто работает в реальном мире, советую рисовать. А потом быстро подбивать время и анализировать:

  • Минута выделена на загрузку какой-то страницы журнала. А эта страница у нас в облаке. И вот первое противоречие. Серверу разрешено 2 минуты, а клиенту 1 минута. Значит у нас 2 варианта вписать, что загрузка журнала будет без данных (только клиент и кэш), либо указать на зависимость того, что журнал не может загрузиться быстрее ответа сервера.

  • Авторизация и аутентификация по минуте. Значит логин в облако займет 2 минуты, только если оба действия будут в одном запросе. И да, если вам понятно, что 1+1 = 2 только в презентации, а на самом деле есть еще прослойки верификаций, сериализации и тому подобное, то контракту это безразлично. Поэтому либо явным образом указывайте логин в таблице со всеми поправками, либо мелкий текст агрегация функций будет вносить дополнительную задержку в процесс.

  • В сложных процессах стоит сделать картинку для клиента, чтоб явно было видно - внешний таймер не может быть меньше суммы внутренних:

Downtime breakdownDowntime breakdown

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

На каждую строку в таблице нужно расписать точный сценарий с минимальным шумом. Лучше всего оторванный от жизни (лабораторный) и с учётом погрешностей. Задача дать настолько подробное описание, чтоб две разные команды на разных тестовых стендах смогли повторить и получить одинаковые данные. Retestability. Берём логин как пример:

Сервис Login выполненный на системе в сети (указываете состояние и скорость сети до сервера), клиентское приложение на машине с рекомендованными параметрами или выше (расписываете железо, включая скорость дисков), с системой включающей только минимально необходимое (лист prerequisites) в оптимальной конфигурации (ссылка на ваши документы) и горячем состоянии (после рестарта станции сделано 3 логина и тестируется только 4-ый успешный, и не позже чем через 5 секунда с последнего), без взаимодействия со внешними системами (всякие sso, oauth провайдеры, active directory и тд), с уровнем логирования (какой-то минимум) в 11 утра во вторник (это важно, если у вас сервер в облаке у инфраструктуры есть нагрузка и без вас) без особых событий (чемпионаты, чёрные пятницы и эпидемии), при ручном замере от нажатия клавиши ввод (триггер начала процесса старт таймера), до появления приветственной надписи такая то (конечная точка стоп таймера) в процессе без ошибок (может случиться какой-нибудь переезд/перенаправление сервисов) займёт не больше 2 секунд в 99% случаев (нужен временной промежуток, допустим месяц) с поправкой 280 мс х 2 на человеческую реакцию. Скрипт для приведения баз данных в эталонное состояние прилагается (ведь важно сколько юзеров и какая сложность ролей и размер базы). Почему это важно я уже упоминал в прошлых статьях, но приведу еще пару примеров ниже.

Из опыта:

Первый логин в систему после ночи занимал в 3 раза больше времени, чем следовало. По данным заказчика, вместо прописанных 5 секунд было 17. Последующий логин, кстати, занимал всего 1.5 секунды. В нашей лаборатории на тестах было 9 секунд, но всё равно больше 5. Выяснилось, что клиент замерял время от провода смарт-карты в пинпаде, а мы вводили данные в форме приложения. Мелочь, но в переговорах сразу понизило пламя - 9 не 17. Начали разбирать процесс. Помимо того, что ночью антивирус забирал ресурсы и клиентская аппликация падала в пейдж, так еще и внешняя система распознавания карты работника требовала разрыва сессии, реинициализации соединения и оживала медленно. Антивируса быть не должно было, но у нас нигде не было указанно, что нельзя. То, что внешняя система нас тормозит, тоже никого не волновало. Ну и сама абсурдность кризиса, что только первый и единственный юзер в день ждёт лишние секунды смущала только меня, но не адвокатов. В контракте есть такая точка старт обслуживания , после которой баги уже не по гарантии, а за деньги (обычно подпиской). Эта точка приближалась, и заказчик решил продлить гарантию открыв спор по SLA. Учитывая, что разработка системы разогрева, перенос интеграции карт в отдельный модуль с отдельным прогревом заняли около месяца, 3 стадии тестирования с последующей публикацией в прод. еще 2 недели, а потом еще не один месяц на обновление всех клиентов (по контракту на новую версию за раз не могло перейти больше 10% локаций в неделю, чтоб снизить риск), то заказчик выиграл пол года.

Требования между строк

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

Загвоздка безопасности в том, что тут, зачастую, не может быть обратной совместимости. Подозрительные люди говорят вам, что у них есть копия ключа от вашего офиса. Вы же не вставите новый замок в соседнюю дверь, оставив в основной старый. Даже если будет куча тех, кому вы не смогли сразу выдать новый ключ. Так и тут. Если сломали щиты, то либо в проде появляются сразу две системы: новая и старая, и постепенно идёт миграция пользователей из уязвимой в защищенную версию. Либо мы всё ломаем и есть только новая версия и те, кого мы не обслуживаем до обновления. И тут вы опять упрётесь рогами в те же ворота SLA о доступности системы.

Эхо из прошлого.

Клиентская часть системы жутко тормозила на первых версиях 7-ой винды на машинах с 1 Gb RAM. Когда подписывался контракт в ходу была ХР. В Энтерпрайз не заходят все версии, особенно если есть специфические драйвера и сборки. А потом SSL скомпрометировали, а более защищённая версия TLS уже не имела поддержки в старой оси. Никаким бубнами заставить работать плавно и хорошо не удалось. Штраф был в пол суммы контракта. Так что, потеряв месяц+ на оптимизации пришлось обращаться к компании, которая обслуживала железо этого клиента (всё та же боязнь vendor lock) и оплатить покупку двух линеек по два гига на 10 тысяч машин по всей стране с установкой (техник на выезде в каждую точку). В данном случае никаких хитростей со стороны заказчика не было переход на другую операционку был вынужденный (требование сектора), а наша система действительно была нежизнеспособна в этих условиях.

Кстати, о доступности. Вы ведь понимаете, что доступность для пользователя системы с облачным сервисом будет равна устойчивости машины, соединения, электроснабжения и только потом эти хвалёные 99.99999. Заказчика мало волнует то, что где-то в облаке всё работает, если конкретный человек в конкретном офисе не сможет этим воспользоваться. Так что объясните это хорошо своим коллегам (на пальцах, как у якудза), которые будут подписывать. Самые простые для понимания примеры в комбинаторике монетки и кубики: У нас есть несколько кубиков, каждый на 365 граней и представляют собой доступность или надежность инфраструктуры в годовом масштабе. Подставляем данные, я люблю использовать полу-реальные данные со своего лаптопа на примере доступа к электронной почте некий облачный жи-mail. Открываете логи раутера, журнал оси и показываете пару записей о перезагрузке или разрыве соединения, а потом экстраполируете на месяц и год. Допустим за последний год у нас не было электричества 17 часов, лаптоп был в ремонте 30 часов, проблемы с соединением 4 минуты в сутки, а это 24 часа в год. И последний кубик недоступность самого облака, которая будет не больше часа в год. Так как любая из этих проблем означает отсутствие доступа к мейлам, то шанс проверить жи-почту в прошлом году был:

availability-probabilityavailability-probability

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

Ещё разок вернёмся к пункту 10 в таблице требований. Что конкретно он означает: интервал синхронизации или временной лимит работы в оффлайн? Двусмысленность в контракте лучше не допускать. Если вам повезло, и компания аудитор выступает арбитром во время всего периода развёртывания, то это уменьшит риск разночтений. Аудиторы страшный враг вашей компании и ваш хороший друг. Они будут мешать эффективным менеджерам игнорировать заявленные процедуры и не применять продемонстрированные процессы, но зато смогут помочь объяснить клиенту сложность некоторых требований и прийти к компромиссам.


Подробнее..

Архитектура архитектуры. Шаг 4 воспалённый аппендикс

11.04.2021 12:12:58 | Автор: admin

Продолжение. К предыдущим постам и карте цикла.

Да, если аппендикс запустить, то будет больно. Ну а пока, возрадуемся же выигранному конкурсу! Ожидать горы золота или похвалы будет как минимум глупо. Солнце ещё высоко и время работать. Дядюшка Скрудж не выстроил бы своей империи, если б сразу бил по рукам и переходил к оплате. Поэтому его воплощение в вашем энтерпрайз-заказчике в очередной раз просто улыбнётся и опять поправит очки. Это, внучка, чтобы получше тебя видеть. И, конечно, чтоб читать текст приложений к контракту мелким шрифтом. Техническая часть всегда запрятана где-нибудь в Appendix 7/C.1.1

Copy of a written deal by Christoph Haizmann from 1669.Copy of a written deal by Christoph Haizmann from 1669.

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

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

Пятиминутка ненависти и личного опыта

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

Ищите самые большие классы

Места с максимальной цикломатической сложностью

Покрытие юнит тестами

Автоматические тесты интеграции

Ищите триггеры и процедуры в базе данных (особенно если это сиквел)

Вы скажете, а в чём секрет это же стандартные метрики кода! А секрет в том, что почему-то никто их не смотрит! Даже хвалёные аудиторы. Иначе как можно купить IP на монолит без тестов с классами по 10000 строк, switch на 600 кейсов и половину бизнес логики в процедурах. Ненависть! Но стоит понимать, что частая ошибка покупающей стороны в том, что они думают, что покупают продукт. А такового никогда не было. Была команда. Как только эта команда покидает судно, оказывается, что они держали все доски голыми руками и без этих рук это даже не лодка, а просто куски древесины в солёной, от слез покупателя, воде.

Функциональные требования

Начнём с очевидного, но невероятного. Помните на первых этапах подачу иконостаса с тех. стеком? Так вот время его перепроверить на соответствие всем изложенным в задании сценариям. И самое главное - передать ответственным игрокам с вашей стороны список жёстких конструкций. Таких жёстких, что легко ломают не только мозг при осмотре, но и спину при падении. У каждой технологии есть ограничения. Эти границы могут сильно влиять на бизнес. Для отдела продуктового дизайна и для вашего клиента подобные вещи совсем не очевидны. Даже если для вас это настолько тривиально, что и упоминания не стоит. Самым популярным кейсом будет не требование работы в оффлайн с полностью облачным бекэндом. Это на втором месте. На первом конечно же полная согласованность всех данных с постоянной доступностью в распределенной системе. На этом невысказанном предположении зачастую строится очень много критического функционала. Сколько бы раз вы не повторяли мантру Брюера все будут считать это какой-то теоретической лабудой. Мы то не в каменном веке, вот сейчас как сделаем Даже эксперты, которых вам предлагают облачные платформы в 80% (5 из 6 на моём опыте) уверены, что если вы работаете по well-architectured шаблонам, то никаких проблем с согласованностью данных не будет. Это проблемы конкурентов. В нашем облаке такого быть не может!.

Всё что нам необходимо, это чтоб везде, где в контракте есть конкретные технологии, требования и сроки, была приписка мелким шрифтом, что возможны изменения. Типа конкретная технология будет выбрана непосредственно перед/вовремя реализацией или если требование не вступает в конфликт с ограничениями технологий или это или альтернативное решение. Дело в том, что такие вещи просто необходимы ввиду длинного срока разработки. Изменения и дополнения к требованиям неизбежны, и вот именно те, которых еще нет и которые нельзя проверить уже сейчас, станут проблемой. Основной причиной будет выход первых версий в реальную жизнь (через год разработки). Это всегда сюрприз, как зима для коммунальщиков. Я ведь уже упоминал, что тендер пишут люди, которым с продуктом не работать. Так возникает требование использовать приватную криптоэкосистему для аудита финансовых операций. Вполне логично, что если пользователь перевёл деньги, то ни сумма, ни реквизиты измениться не могут и не должны, так что давайте схороним их под грифом хранить вечно c цифровым сургучом. Хайповый блокчейн тут как раз в кейс. Потом продукт попадает на рабочий стол клерка одной маленькой европейской страны, который работает с вашим софтом и, что самое главное, с живыми людьми и деньгами в физическом мире. И тут возникают нюансы. При вкладе наличных он часто ошибается в выборе валюты или записи суммы. Раньше он просто заходил и правил транзакцию на месте, перед тем как выдать квиток клиенту для подписи. Теперь транзакция в реальном времени уходит в сотню точек, а документ закрыт на замок и не принимает правки, да ещё и сам лезит на печать. Если вы всё еще думаете, что только русский язык богат на ругальства, то вам просто не довелось слушать запись звонка почтальона из деревеньки на Корсике в службу поддержи вашего продукта. Ваш клиент хочет просто добавить возможность редактирования, а вы начинаете ему объяснять, что это невозможно. Что нужно поменять подход в привычном бизнес-сценарии вносить корректировочные транзакции, менять отчёты и рапорты. И обновлять внешние системы, которые не знают о существовании нового типа документов, и не являются частью вашего продукта, а просто питаются экспортированными данными для отчётов и всякой аналитики. Ну и вот это вот всё, что работало и копилось годами.

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

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

Нефункциональные требования

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

Appendix HeaderAppendix Header

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

Номер

Требование

Время

1

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

10 минут

2

Максимально допустимое время на синхронизацию клиента

5 минут

3

М.д.в. отклика облачного центра

2 минуты

4

М.д.в время загрузки страницы журнала

1 минута

5

Минимальное время хранения записи в журнале

5 лет

6

М.д.в аутентификации пользователя

1 минута

7

М.д.в авторизации пользователя

1 минута

8

М.д.в перезагрузки системы

3 минуты

9

М.д.в недоступности системы для операций (в месяц)

5 минут

10

М.д.в рассинхронизации данных между клиентом и облаком

5 минут

И всё в таком духе. Абстрактный сценарий и какой-то лимит времени. Тот, кто эти цифры даёт ваш заказчик. Ему не нужно с этим разбираться. Он просто озвучивает желания. Желания всегда ведут к результату лестницей Пенроуза. Так что в начале нужно разобрать всё, ступенькой за ступенькой, и сложить всё в поленницу. А потом упорядочить и структурировать. Что значит структурирование? Построить цепочку зависимостей сценариев в последовательности исполнения. Рассмотрим наш теоретический пример. Сразу скажу, что работать лучше на листе или доске, так как в красивые деревья не вырастут. Будет сложная диаграмма или зацикленные графы. Я вот подобрал удобные сценарии, но всё равно нарисовать в ворде получается, как-то не очень:

Scenario TreeScenario Tree

С подобной диаграммой работать легче, а самое главное намного проще объяснить другим. Надо сразу вписывать недостающие шаги. Допустим процесс логина в таблице отсутствует, но его составляющие есть. Опять-таки, если вокруг вас все специалисты и у вас такой авторитет, что решения объяснять не надо, то можно и пропустить живопись. Вполне ведь себе реальная ситуация, что технический специалист со стороны исполнителя просто говорит: тут вот будет 5 вместо 2 - и заказчик сразу соглашается. Тем же, кто работает в реальном мире, советую рисовать. А потом быстро подбивать время и анализировать:

  • Минута выделена на загрузку какой-то страницы журнала. А эта страница у нас в облаке. И вот первое противоречие. Серверу разрешено 2 минуты, а клиенту 1 минута. Значит у нас 2 варианта вписать, что загрузка журнала будет без данных (только клиент и кэш), либо указать на зависимость того, что журнал не может загрузиться быстрее ответа сервера.

  • Авторизация и аутентификация по минуте. Значит логин в облако займет 2 минуты, только если оба действия будут в одном запросе. И да, если вам понятно, что 1+1 = 2 только в презентации, а на самом деле есть еще прослойки верификаций, сериализации и тому подобное, то контракту это безразлично. Поэтому либо явным образом указывайте логин в таблице со всеми поправками, либо мелкий текст агрегация функций будет вносить дополнительную задержку в процесс.

  • В сложных процессах стоит сделать картинку для клиента, чтоб явно было видно - внешний таймер не может быть меньше суммы внутренних:

Downtime breakdownDowntime breakdown

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

На каждую строку в таблице нужно расписать точный сценарий с минимальным шумом. Лучше всего оторванный от жизни (лабораторный) и с учётом погрешностей. Задача дать настолько подробное описание, чтоб две разные команды на разных тестовых стендах смогли повторить и получить одинаковые данные. Retestability. Берём логин как пример:

Сервис Login выполненный на системе в сети (указываете состояние и скорость сети до сервера), клиентское приложение на машине с рекомендованными параметрами или выше (расписываете железо, включая скорость дисков), с системой включающей только минимально необходимое (лист prerequisites) в оптимальной конфигурации (ссылка на ваши документы) и горячем состоянии (после рестарта станции сделано 3 логина и тестируется только 4-ый успешный, и не позже чем через 5 секунда с последнего), без взаимодействия со внешними системами (всякие sso, oauth провайдеры, active directory и тд), с уровнем логирования (какой-то минимум) в 11 утра во вторник (это важно, если у вас сервер в облаке у инфраструктуры есть нагрузка и без вас) без особых событий (чемпионаты, чёрные пятницы и эпидемии), при ручном замере от нажатия клавиши ввод (триггер начала процесса старт таймера), до появления приветственной надписи такая то (конечная точка стоп таймера) в процессе без ошибок (может случиться какой-нибудь переезд/перенаправление сервисов) займёт не больше 2 секунд в 99% случаев (нужен временной промежуток, допустим месяц) с поправкой 280 мс х 2 на человеческую реакцию. Скрипт для приведения баз данных в эталонное состояние прилагается (ведь важно сколько юзеров и какая сложность ролей и размер базы). Почему это важно я уже упоминал в прошлых статьях, но приведу еще пару примеров ниже.

Из опыта:

Первый логин в систему после ночи занимал в 3 раза больше времени, чем следовало. По данным заказчика, вместо прописанных 5 секунд было 17. Последующий логин, кстати, занимал всего 1.5 секунды. В нашей лаборатории на тестах было 9 секунд, но всё равно больше 5. Выяснилось, что клиент замерял время от провода смарт-карты в пинпаде, а мы вводили данные в форме приложения. Мелочь, но в переговорах сразу понизило пламя - 9 не 17. Начали разбирать процесс. Помимо того, что ночью антивирус забирал ресурсы и клиентская аппликация падала в пейдж, так еще и внешняя система распознавания карты работника требовала разрыва сессии, реинициализации соединения и оживала медленно. Антивируса быть не должно было, но у нас нигде не было указанно, что нельзя. То, что внешняя система нас тормозит, тоже никого не волновало. Ну и сама абсурдность кризиса, что только первый и единственный юзер в день ждёт лишние секунды смущала только меня, но не адвокатов. В контракте есть такая точка старт обслуживания , после которой баги уже не по гарантии, а за деньги (обычно подпиской). Эта точка приближалась, и заказчик решил продлить гарантию открыв спор по SLA. Учитывая, что разработка системы разогрева, перенос интеграции карт в отдельный модуль с отдельным прогревом заняли около месяца, 3 стадии тестирования с последующей публикацией в прод. еще 2 недели, а потом еще не один месяц на обновление всех клиентов (по контракту на новую версию за раз не могло перейти больше 10% локаций в неделю, чтоб снизить риск), то заказчик выиграл пол года.

Требования между строк

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

Загвоздка безопасности в том, что тут, зачастую, не может быть обратной совместимости. Подозрительные люди говорят вам, что у них есть копия ключа от вашего офиса. Вы же не вставите новый замок в соседнюю дверь, оставив в основной старый. Даже если будет куча тех, кому вы не смогли сразу выдать новый ключ. Так и тут. Если сломали щиты, то либо в проде появляются сразу две системы: новая и старая, и постепенно идёт миграция пользователей из уязвимой в защищенную версию. Либо мы всё ломаем и есть только новая версия и те, кого мы не обслуживаем до обновления. И тут вы опять упрётесь рогами в те же ворота SLA о доступности системы.

Эхо из прошлого.

Клиентская часть системы жутко тормозила на первых версиях 7-ой винды на машинах с 1 Gb RAM. Когда подписывался контракт в ходу была ХР. В Энтерпрайз не заходят все версии, особенно если есть специфические драйвера и сборки. А потом SSL скомпрометировали, а более защищённая версия TLS уже не имела поддержки в старой оси. Никаким бубнами заставить работать плавно и хорошо не удалось. Штраф был в пол суммы контракта. Так что, потеряв месяц+ на оптимизации пришлось обращаться к компании, которая обслуживала железо этого клиента (всё та же боязнь vendor lock) и оплатить покупку двух линеек по два гига на 10 тысяч машин по всей стране с установкой (техник на выезде в каждую точку). В данном случае никаких хитростей со стороны заказчика не было переход на другую операционку был вынужденный (требование сектора), а наша система действительно была нежизнеспособна в этих условиях.

Кстати, о доступности. Вы ведь понимаете, что доступность для пользователя системы с облачным сервисом будет равна устойчивости машины, соединения, электроснабжения и только потом эти хвалёные 99.99999. Заказчика мало волнует то, что где-то в облаке всё работает, если конкретный человек в конкретном офисе не сможет этим воспользоваться. Так что объясните это хорошо своим коллегам (на пальцах, как у якудза), которые будут подписывать. Самые простые для понимания примеры в комбинаторике монетки и кубики: У нас есть несколько кубиков, каждый на 365 граней и представляют собой доступность или надежность инфраструктуры в годовом масштабе. Подставляем данные, я люблю использовать полу-реальные данные со своего лаптопа на примере доступа к электронной почте некий облачный жи-mail. Открываете логи раутера, журнал оси и показываете пару записей о перезагрузке или разрыве соединения, а потом экстраполируете на месяц и год. Допустим за последний год у нас не было электричества 17 часов, лаптоп был в ремонте 30 часов, проблемы с соединением 4 минуты в сутки, а это 24 часа в год. И последний кубик недоступность самого облака, которая будет не больше часа в год. Так как любая из этих проблем означает отсутствие доступа к мейлам, то шанс проверить жи-почту в прошлом году был:

availability-probabilityavailability-probability

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

Ещё разок вернёмся к пункту 10 в таблице требований. Что конкретно он означает: интервал синхронизации или временной лимит работы в оффлайн? Двусмысленность в контракте лучше не допускать. Если вам повезло, и компания аудитор выступает арбитром во время всего периода развёртывания, то это уменьшит риск разночтений. Аудиторы страшный враг вашей компании и ваш хороший друг. Они будут мешать эффективным менеджерам игнорировать заявленные процедуры и не применять продемонстрированные процессы, но зато смогут помочь объяснить клиенту сложность некоторых требований и прийти к компромиссам.


Подробнее..

Архитектура архитектуры. Шаг 5 один за всех и все на одного

18.04.2021 04:18:58 | Автор: admin

Продолжение. К предыдущим постам и карте цикла.

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

Unus pro omnibus, omnes pro unoUnus pro omnibus, omnes pro uno

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

Agile development conceptAgile development concept

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

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

Architecture on feature mapArchitecture on feature map

Возвращаясь к первой статье цикла, ещё раз озвучу своё мнение о назначении архитектуры. Это оптимальный путь решения задач бизнеса. При выборе паттернов проектирования, методологии работы, технологий и фреймворков, мы всегда получаем набор функций и решений, которые работают из коробки и набор ограничений из табакерки. Ещё до финальной подписи в контракте на души разработчиков, вы должны были перепроверить всё, что заявлено. Значит основная парадигма у нас есть. Что-то типа: микросервисы в облаке с разбивкой по DDD с локальным клиентом на Java. Полезность правила измеряется количеством исключений. Так что чем меньше перекосов в сторону монолита на клиенте или костылей вокруг облака тем лучше. Тут никакого откровения нет. Но, всё же не хочется быть автором ещё одной пустой статьи из серии мы в компании Х решили всё сделать по У и у нас всё получилось. Ведь я-то как раз и хотел в статьях показать путь, которым приходят к выбору У и как даётся тот самый success story.

Как вы, возможно, читали ранее выбор часто делают за вас. Технологии - из того, что знает команда, методология тоже какая уж есть в вашей корпорации, провайдеры и стандарты обычно определяются заказчиком как одно из требований тендера. Вам же достаётся игра в Counter Strike. Пытаетесь обезвредить бомбы, которые уже заложены. Особенности работы с большими предприятиями я уже описывал. Так что сам по себе пазл не сложится. Облако и микросервисы стандарт де-факто и, почти наверняка, вас не миновала чаша сия. Такие системы всегда обладают атрибутами AP. Значит стоит определить какие узлы требуют CA.

Энтерпрайз системы в основном рассчитаны на использование сотрудниками компании для автоматизации процессов. Зачастую процессы критические и производственные. Значит нужно чётко понимать, что должно работать вне облака. Почтовое отделение, заводик или магазин должны продолжать обслуживать даже, когда облако не доступно (это не облако упало, а ваш клиент потерял соединение). И данные на месте нужны актуальные (тот самый СА вариант). Если мы возьмём за пример систему управления логистикой, где у нас есть куча грузовиков развозящих товары по дорогам страны, то понятно, что никакие изменения данных в облачном диспетчере не изменят содержимое кузова. Ну и совсем не хочется, чтоб этот грузовик простаивал, если у него нет связи с сетью. Значит его локальная система должна иметь возможность учёта товара, просмотра маршрута и управления исключениями, без которых в реальной жизни никак. Глаз в облаке будет довольствоваться данными последней синхронизации и предполагаемым прогрессом (эвристикой текущего состояния). Заявленные микросервисы на планшет водителя устанавливать видимо тоже не стоит. Они уместны в центре управления, высоко в облаках, там, где вершина корпоративной пирамиды. Но процессы и данные у центра и аппликации водителя будут перекликаться процентов на 70. Это как раз и создаёт предпосылки к путаницам с распределёнными и модульными монолитами. Нежелание повторяться приводит к сильно связанным громоздким сервисам и полурабочему зоопарку клиентов.

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

Если вам повезло и логику можно инкапсулировать в модуль, который легко впишется и в сервис, и в аппликацию на планшете (reuse over duplication), то данные всё равно будут жить своей жизнью. Но чем меньше кода, тем лучше. Так что если у вас предполагается работа без доступности центра, то стоит свести внесетевые функции к минимуму. Стандартная отказоустойчивость как часть дизайна. Водитель должен отчитаться о разбитом ящике молока не стоит сразу дублировать форму на случай, если связи нет. Может достаточно создать напоминание об этом событии с принудительным заполнением в конце маршрута и оставить сам рапорт только сервисом на бэке? Не работает встроенный принтер сохраним файл. А иногда и просто добавим бумажный формуляр к планшету, а в аппликации потребуем сделать его снимок.

Ошибки молодости

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

Ну и как найти и учесть все подобные случаи заранее? А никак. Архитектура большого проекта похожа на школьные опыты по биологии. Там, где рассматривают кожицу лука под микроскопом. Сначала вы смотрите на всё со стороны и добавляете контрастную жидкость. Потом вставляете в микроскоп и настраиваете свет, пытаясь остаться в границах на минимальном приближении. И лишь найдя цель, меняете увеличение на максимум фокусируетесь на деталях. То есть сначала вы делали блок схему, а потом перед непосредственной разработкой будете делать архитектуру каждого блока, заполняя его деталями. По необходимости будете добавлять всякие flow и sequence они легче всего воспринимаются всеми участниками процесса разработки. Так что в отличии от строительства, вы начинаете разработку с наброска, а детальную архитектуру получите лишь в конце. Поэтому так полезны, хоть и не популярны, большие UML пакеты, позволяющие ссылки на диаграммы и вложенные чарты. Разработка это drill down от blue-print до detailed architecture.

Agile architecture conceptAgile architecture concept

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

Всё, что нужно делать вручную, будут игнорировать так или иначе. Начало проекта начало автоматизации. Тут и юнит тесты (для правильного дизайна и возможности рефакторинга), и интеграционные тесты (для стабильности проекта и уменьшения time-to-market), и метрики кода (всевозможные KPI) всё часть CI-CD. Игры в микросервисы с ручной настройкой и развёрткой оставим мазохистам. Нам необходима команда DevOps. Формально или нет, но кто-то должен быть ответственным за правильную конфигурацию и установку среды. Среды разработки, среды проверок, среды интеграции и т.д. Иначе в будущем вместо среды вас будут ждать суббота и воскресенье разработки и проверки. В производственных системах редко можно найти изолированные бизнес-кейсы. Все микросервисы должны будут взаимодействовать друг с другом и между ними будет явная или не явная зависимость. Устранить этот недостаток можно еще одним уровнем абстракции! Cервис оркестратор сервисов. Тот, что вызывает цепочку других сервисов, чтоб обеспечить необходимый результат.

Delivery service orchestrates domain services in business flowDelivery service orchestrates domain services in business flow

Вернёмся к нашему грузовику. Водитель хочет начать маршрут. Для этого необходимо: получить квоту на топливо, заправиться, погрузить товар, подтвердить погрузку, составить маршрут, сообщить на точки отгрузки предположительное время прибытия и так далее. Если каждый этап станет отдельным сервисом, то клиент будет отвечать за бизнес. А хотелось бы чтоб он был как можно тоньше. Удобно группировать несколько таких шагов в один процесс и вызов. Сервис заправки он проверит маршрут, квоту и авторизирует заправку. То есть последовательно запустит 34 микросервиса (с десяток API вызовов и сохранить состояние между ними). Конечный автомат. Плодить такие сервисы бесплатно тоже нельзя. Стоит создать жирненькие мета-сервисы объединяющие кросс-домейн процессы, вместо того, чтоб рулить всем из фронта. Не легковесные они, потому как знают многое о многих и строят сложные процессы взаимодействия. Однако связь односторонняя. Собственно это простой медиатор. Основная причина не раздувать клиентскую часть лежит в разнообразии таких приложений с однообразием и стандартизацией процесса. Абсолютно тот же функционал должен быть доступен в каком-нибудь легаси винформ монолите, нативном андройд клиенте, который кто-то запилил вашему заказчику пару лет назад и новой веб-аппликации из вашего пакета. Очень удобно все три приложения заставить обращаться к одному сервису, сделав миграцию из legacy в nextgen быстрой и легко управляемой.

Помимо планирования есть еще и проверки того, что план соблюдают. Настройка правил статистического анализатора кода и внедрение проектных тестов (solution unit-test), на мой взгляд, задача архитектора. Что такое проектные тесты? Это жесткие правила ломающие билд при нарушении, написанные в виде юнит теста или плагина к какому-нибудь сонару. Примеры подобных тестов:

Минимальное покрытие тестами в определённых модулях

Ограничение по количеству заигнориных тестов

Тест на то, что тест с ограничением тестов в игноре не заигнорин

Список запрещённых референсов (например уровень бизнес-логики не должен знать о типах в базе данных)

Список разрешённых референсов (допустим open source и legacy библиотеки)

Разрешённые типы файлов (к примеру файлов .sql не должно существовать)

Naming и структура проекта (если должно быть 3 слоя и каждый отдельной библиотекой, а тесты заканчиваться на _Test то будьте любезны)

Парсинг и проверка скриптов на соответствие (например скрипт конфигурации должен создавать одноименную запись и в параметрах окружения и в файлах)

Минимальное количество строк лога в каждом классе (если актуально)

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

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

Теперь пора строить план. Что вы должны выдать в качестве необходимого функционала вам сообщат все заинтересованные участники. Надо понять как много (или мало) останется на инфраструктуру. Все Agile, но только, когда им удобно. Выделить месяц на создание основы проекта без деловой логики/функционала, почему-то не хотят. Не достаточно прозрачно. Или сложно тестировать. Все уверены, что основа проекта закладывается с самой сложной формы в UI. Вот gateway ваш, безопасность и мониторинг можно и позже их же всё равно никто не видит. А заказчику нужно что-то показать. Так что опять нужно будет продавать необходимость и своевременность. Как обычно апеллируя к тому, что увеличение числа процессов и компонентов прямо пропорционально стоимости внедрения 3-х С - сквозных системных служб. И, как всегда, создаётся впечатление, что это понимаете вы и пара инженеров, но не управленцы.

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


Подробнее..

Перевод Код-ревью в IDE интеграция между Space и IntelliJ IDEA 2021.1

08.04.2021 20:08:42 | Автор: admin

Привет, Хабр!

Вчера вышло обновление IntelliJ IDEA 2021.1. В него вошла интеграция с JetBrains Space, которая позволяет использовать любую IDE на платформе IntelliJ для код-ревью: назначать ревью и управлять ими, просматривать и добавлять комментарии, принимать изменения. Как это работает, мы подробно расскажем в этом посте.

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

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

Видео

Если вы предпочитаете видео, смотрите обзор этой функциональности от Триши Ги:

Space-плагин встроен в свежую версию IntelliJ IDEA 2021.1. Для других наших IDE плагин нужно установить вручную.

Прежде чем приступить к ревью кода, войдите в Space из IDE. Это можно сделать в настройках: Tools | Space. Введите URL-адрес своей организации Space, нажмите Log In, и ваш дефолтный браузер попросит вас предоставить доступ из IDE.

После этого в Get from VCS появится список всех проектов и репозиториев в вашей организации Space. Найдите и выберите Git-репозиторий, с которого вы хотите начать, и нажмите Clone.

У Space-плагина есть свое окно, в котором можно просматривать задания в Space Automation. Плагин также обеспечивает автодополнение и подсветку синтаксиса для файлов .space.kts.

Но мы здесь из-за код-ревью, так что перейдем к делу.

Окно Code Reviews

Окно Space Code Reviews открывается с боковой панели или через меню Tools | Space | Code Reviews. В нем вы увидите все ревью, относящиеся к текущему проекту. В окне работает поиск и фильтры.

Фильтры помогут отсортировать:

  • Открытые и закрытые ревью;

  • Ревью, в которых содержатся ваши изменения;

  • Ревью, требующие вашего внимания;

  • Изменения, которые вам нужно просмотреть;

  • Ревью, назначенные на вас.

Хронология код-ревью

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

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

В Space важное место занимают чаты. Комментарии к код-ревью это тоже чат: оставляйте дополнительные комментарии и отвечайте коллегам в тредах. Все это не выходя из IDE.

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

Ревью кода в IDE

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

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

Принять изменения или дождаться ответа

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

  • Accept Changes, то есть принять изменения, если на ваш взгляд с кодом все в порядке.

  • Wait for Response, то есть подождать ответа, если вы ознакомились с изменениями, но у вас остались вопросы или в коде есть нерешенные проблемы.

В любом случае ваш этап проверки будет завершен и ваши комментарии будут опубликованы.

Заключение

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

Space-плагин встроен в IntelliJ IDEA 2021.1, а для других наших IDE его можно установить вручную.

Вы можете бесплатно зарегистрироваться в Space и легко создать зеркало существующего Git-репозитория, чтобы пользоваться всеми возможностями Space для код-ревью в IntelliJ IDEA.

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

Подробнее..

Перевод Daily Standup пустая трата времени

07.04.2021 16:22:59 | Автор: admin

Обычный рабочий день. Тот же самый daily standup, который вы посещаете годами. Вы приходите в одно и тоже время. Немного общаетесь со своими товарищами по команде. Потом руководитель интересуется, как вчера прошла чья-то работа.

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

Этот формат вроде как работает.

Я имею в виду, что для одних команд это нормально, а для других отстой. Почему люди жалуются на daily standup на командных встречах? Почему одним это нравится, а другим нет? Поразмыслив над этим в течение нескольких лет, я пришел к следующему выводу:

Меня не волнует, что ты сделал вчера.

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

Меня волнует, насколько команда продвинулась к своим целям.

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

Имеет ли значение daily standup?

Что такое daily standup?

Если вы не знакомы с daily standup, то это ежедневное собрание команды для обсуждения текущего проекта. Оно длится порядка 15 минут и предполагает, что каждый человек отвечает на следующие вопросы:

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

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

  • Какие препятствия мешают мне или команде достичь поставленных целей?

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

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

Проблемы формата Daily Standup

Проблемы с традиционным daily standup это отсутствие фокуса и обсуждение не по теме. Когда я прихожу на эту встречу, у меня в голове возникают следующие мысли:

  • Я начинаю думать о своем вкладе, чтобы доказать свою полезность;

  • Люди отключаются, когда товарищ по команде начинает говорить о том, что их напрямую не касается;

  • Наконец-то настала моя очередь сообщать о проделанной работе. Но никто не слушает, кроме руководителя;

  • Мы выходим за временные рамки и заканчиваем, когда другая команда начинает мельтешить у входа в комнату в ожидании своего daily standup.

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

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

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

  • Больше людей приносят больше нововведений.

  • Больше нововведений больше информации, на которую другим людям будет наплевать.

  • Команда может работать сразу над несколькими проектами.

  • Если у команды есть клиенты, то регулярно будут озвучиваться особые виды деятельности.

Проще говоря, традиционный формат daily standup не масштабируется.

Масштабируемый формат daily standup: Walk the Board

Я добился большого успеха в использовании формата Walk the Board для больших ежедневных выступлений. Этот формат по-прежнему отвечает на критические вопросы:

  • Что было сделано вчера?

  • Что запланировано на сегодня?

  • Что мешает команде добиться прогресса?

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

Этот формат работает следующим образом:

  • Создайте доску, на которой будет отображаться статус каждого элемента, над которым работает команда.

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

  • Обязательно спросите: Что нужно, чтобы переместить этот элемент на следующий этап прогресса?

  • Выделите проблемы, мешающие работе.

  • Перейдите к следующему столбцу слева и получите обновления для каждого тикета в этом столбце.

  • Продолжайте, пока не дойдете до самого левого столбца.

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

Теперь может показаться, что этот формат занимает много времени. Но это не так!

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

Что делать, если формат Walk the Board слишком долгий?

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

Если вам нужно обсудить слишком много вещей , стоит подумать, как ваша команда может взять на себя меньше элементов? Как исправить это тема для другого разговора. А пока я рекомендую прочитать книгу Agile Project Management with Kanban.

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

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

Значение играет не сам Daily standup, а время после него.

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

Все в команде общаются.

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

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

Это заставило меня понять, что настоящая ценность daily standup не сама встреча, а время, которое наступает после неё.

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

Заключение

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

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

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

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

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

Подробнее..

Перевод Простая жизнь людей

07.04.2021 20:14:16 | Автор: admin

В связи со скорым стартом онлайн-курса "Team Lead" приглашаем всех желающих записаться на открытый демо-урок Первые шаги тимлида на новом месте. На вебинаре участники вместе с экспертом обсудят:
С чего начать работу новоиспеченному лиду?
На какие процессы стоит обращать внимание?
В каких местах кроются quick wins для быстрого роста?

А сейчас предлагаем к прочтению традиционный перевод интересного материала.

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

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

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

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

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

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

Всё должно быть сделано просто насколько возможно, но ничуть не проще. Это высказывание Эйнштейна неправильно цитируют, упуская из вида последнюю часть, но ничуть не проще, или как он сказал самом деле: адекватное представление базовой единицы опыта (the adequate representation of a single datum of experience). Я думаю, что Эйнштейн пытается сказать, что цель не простота, а понимание.

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

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

Хомский (Chomsky) и Герман (Herman), вероятно, наиболее известны тем, что описали, как подобные методы работают в пропаганде. Они утверждают, что, ограничивая параметры дискуссии, мы фактически вырабатываем одобрение общественности. Что, на мой взгляд, работает как для общества, так и для организаций.

Например, можно упростить сложный набор идей в крылатую фразу, с которой трудно не согласиться, например Сделаем Америку снова великой (Make America great again), Надежда (Hope), Перемены (Change), Мир (Peace) и т. д. Это заставляет нас ощущать глубину дискуссии где-то на уровне детского бассейна; когда на самом деле ее глубина подобна океану. Поддерживаете ли вы наши войска? это не тот же вопрос что Поддерживаете ли вы политику, связанную с войной, в которой они сражаются?. Хомский говорит, что вы должны НАЧАТЬ, сказав: Ну, я НЕ не поддерживаю войска, но к тому времени вы уже проиграли.

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

Простота идеальное средство радикализации монистической мысли.

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

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

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

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

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

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

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

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

Cynefin framework отправная точка для работы со сложностью

A Leader's Framework для принятия решений

Можете ли вы упростить сложность?

На Media ч. 1 - Согласие на производство (подкаст)


Узнать подробнее о курсе "Team Lead".

Смотреть вебинар Первые шаги тимлида на новом месте.

Подробнее..

YouTrack теперь с центром уведомлений

07.04.2021 20:14:16 | Автор: admin

Привет, Хабр!

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

Держите руку на пульсе

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

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

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

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

Время под контролем: теперь и в YouTrack Lite

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

Связь с внешним миром: ссылки в строковых полях

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

Поиск полного дерева подзадач

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

Этот синтаксис можно применять не только к типу связи подзадача, но и ко всем типам связи с направленностью объединение, например, к дубликатам (совокупность дубликат: ID задачи)

Иерархия групп

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

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

Дополнительные поля в профилях пользователей

Помимо учетных данных, имен и электронных адресов, в профилях пользователей теперь можно указывать дополнительную информацию например, телефонные номера или должности сотрудников. Рабочие процессы (workflows) YouTrack тоже могут оперировать этими полями. Например, вы сможете разрешить выполнение определенных действий только генеральному директору компании. Кроме того, настраиваемые атрибуты могут быть синхронизированы с AD-сервером (или любым LDAP-сервером) и доступны через REST API Hub, что открывает еще больше возможностей для автоматизации.

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

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

Команда YouTrack

Подробнее..

Organization as a Function. Введение в бережливую разработку для инженеров

08.04.2021 16:21:10 | Автор: admin

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

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

Наша программа правильно выполняла свою задачу: на экране в бешеном темпе курсор прыгал по ячейкам, писал в них формулы, выделял диапазоны данных. Выполнение программы занимало 40 минут, а загруженность процессора была 100%. Мы хотели быстрее. Может быть, надо запустить программу на компьютере помощнее? Или написать распределенную программу и собрать компьютеры в кластер? Любой здравомыслящий программист поймет, что это плохие решения и ускорения можно добиться куда более простыми методами. Мы исследовали причины низкой производительности и обнаружили, что вся проблема была в том, что программа механически повторяла методические указания. Гораздо эффективнее было не повторять поведение человека в Excel, а перенести все данные из таблицы в память, выполнить необходимые расчеты и записать результаты обратно. Новая версия программы работала 50 мс, так мы оптимизировали программу приблизительно в 50000 раз.

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

В производстве подобные приемы были созданы в Toyota и назывались Toyota Production System. Эти приемы были обобщены до бизнеса в целом в виде философии кайдзен. В области разработки программного обеспечения их называют приемами бережливой разработки программного обеспечения.

Согласитесь, как здорово улучшить работу организации в 50 000 раз! Это, конечно, сказки, но и 10% может быть весьма неплохо.

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

Моделируем организацию

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

Прибыль = доходы - расходы

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

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

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

  • Сервис должен надежно и правильно работать. Если он не работает или работает не так, то грош цена всей его функциональности.

Программисты вкладываются в обе составляющие наряду с командами инфраструктуры и DevOps.

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

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

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

Вернемся к аналогии про оптимизацию программного обеспечения.

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

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

Приступим к оптимизации!

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

def joom(market_info, money_from_user):    requirements = product_manager(market_info, money_from_user)    infra = infra_team()    while True:        new_release = product_team(requirements, infra)        if quality_control(new_release, requirements, infra):            service = deploy_to_production(new_features)            return service

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

Удаляем мертвый код

Это самый низко висящий фрукт. Если какие-то вычисления не влияют на результат функции, то этот код надо просто удалить.

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

Взгляните на этот пример

def product_team(requirements, infra):    long_useless_meeting() # what is that for? Let's remove it.    implementation_plan = plan(requirements, infra)    log.debug(implementation_plan) # if logging is fast enough, we can leave it here    return code(implementation_plan, requirements, infra)

Если некоторая деятельность в организации не приводит к профиту пользователя прекратите это делать.

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

  • Если что-то нельзя не делать, то тратьте на это минимум ресурсов.

Реализуем только полезную функциональность

Посмотрим на организацию как функцию еще раз.

def joom(market_info, money_from_user):    # something    return service

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

def test():    service = joom(some_marketing_info, previous_money_from_user)    assert makes_money(service)

Представьте себе, что функция joom оказалась с багами и периодически она по непонятным причинам выдает некорректные значения. Если мы не можем исправить ошибку, то придется делать retry вот так:

def profitable_joom(market_info, money_from_user):    while True:        service = joom(market_info, money_from_user)        if makes_money(service)            return service

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

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

def joom(market_info, money_from_user):    requirements = product_manager(market_info, money_from_user)    assert makes_money(requirements) # fail-fast if cannot make money    infra = infra_team()    while True:        new_release = product_team(requirements, infra)        assert makes_money(new_release) # fail-fast if cannot make money        if quality_control(new_release, requirements, infra):            service = deploy_to_production(new_features)            assert makes_money(service) # fail-fast if cannot make money            return service

Мы добавили assert для промежуточных результатов. Теперь в случае ошибки мы можем сделать retry раньше и избежать потерь ресурсов.

Вопрос для размышления читателю. А что если сама функция makes_money подвержена ошибкам?

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

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

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

  • Реализовали не то, что хотели потери в коммуникации.

  • Реализовали то, что хотели, но оно не работает из-за потерь качества.

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

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

Любой метод выбора правильных идей требует ресурсов и может давать ложные результаты.

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

А если проверка идеи ложно говорит, что она плохая, то вы не будете делать перспективные идеи. Если вы проверили идею и отвергли ее, то ресурсы, потраченные на проверку, не были скомпенсированы доходом. Это прямые потери. Довод зато мы не потратили еще больше ресурсов на реализацию бессмысленной идеи не работает: потери есть потери. Команда, которая тратит все свое время на отбрасывание идей это мертвый код, так как ее работа не влияет на результаты. Такой команде стоит задуматься о смысле своего существования. В нашей аналогии с исходным кодом это такая функция, которая постоянно проваливает assert makes_money.

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

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

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

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

def profitable_joom(market_info, money_from_user):    while True:        mvp_service = joom_prototyping(market_info, money_from_user)        if makes_money(mvp_service):            service = joom(market_info, money_from_user)            if makes_money(service)                return service

Это классический метод оптимизации. Например, он широкого распространен в форме double check locking.

Минимизируем бюрократию

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

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

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

def product_team(requirements, infra):    implementation_plan = plan(requirements, infra)    return code(implementation_plan, infra)

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

SCRUM, KanBan, planning poker, недельные отчеты, квартальное планирование, peer review и т.п. все это инструменты повышения продуктивности. Я собирательно назвал их бюрократией, но не вкладываю в это понятие негативную оценку.

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

  • устраняет потери ресурсов из-за недостатка коммуникации,

  • устраняет потери из-за вытеснения одних задач другими,

  • мотивирует сотрудников к профессиональному росту,

  • улучшает фокусировку на том, что принесет максимальную пользу,

  • создает ритм работы с регулярными промежуточными результатами.

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

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

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

Я работаю в команде Joom Ads, и мы отвечаем за рекламу в маркетплейсе. Когда мы начинали работать над проектом, мы намеренно не делали никакого процесса (AdHoc), но затем, по мере роста команды и сложности разработки, мы стали обращать внимание на потери и адаптировали свои процессы. Сейчас наш процесс эволюционировал в KanBan с continuous delivery, практически все рутинные процессы автоматизированы.

Вопрос для размышления читателю. Чтение этих строк приносит пользу?

Используем эффективные алгоритмы

При написании кода важно использовать эффективные алгоритмы. Лучше использовать алгоритм со сложностью O(NLogN) вместо O(N2). Но если вдруг N небольшое, то никакой практической разницы между этими двумя алгоритмами может не быть, можно воспользоваться алгоритмом со сложностью O(N2), к тому же такие алгоритмы, как правило, проще. Проблемы с таким решением начнутся, если N начнет расти.

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

Например:

def product_team(requirements, infra):    for implemented in already_implemented:        if implemented == requirements:            return None    implementation_plan = plan(requirements, infra)    release = code(implementation_plan, requirements, infra)    already_implemented.append(requirements)    return release

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

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

Управляем техническим долгом

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

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

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

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

Инвестируем в рефакторинг

Исправление технического долга это техническая инвестиция, так как она не окупается быстро.

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

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

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

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

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

Инвестируем в библиотеки и инструменты

А как оценить инвестицию не в рефакторинг, а в некоторый инструмент или библиотеку? Стоит ли взять какой-то open source инструмент или написать своё будет продуктивнее? Ведь со сложным open source придется разбираться, это потребует ресурсов, а написать свой инструмент будет даже быстрее.

Главный вопрос при создании велосипедов а что будет дальше?

Пока на написание и поддержку своего инструмента уходит меньше времени, чем на изучение open source, профит точно есть.

Но вот если планируется развивать свое решение и сделать его конкурентом существующему open source, то вам надо будет окупить следующие затраты.

  • Создание и отладку инструмента. Open source уже прошел этот путь.

  • Поддержку инструмента своими силами. У open source есть community для этого.

  • Написание качественной документации. Про open source могут быть написаны книги, как минимум множество ответов в stackoverflow и т.п.

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

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

Тем не менее создание собственного решения может быть продуктивным.

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

  • Бывают низкокачественные open source решения. Они постоянно требуют ресурсов на поддержку, и починить их уже почти невозможно вашими силами из-за огромного технического долга в самом решении.

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

В ходе разработки JoomAds нам не довелось изобретать велосипеды, мы брали существующие инструменты, порой внося изменения в их код и исправляя баги. К сожалению, некоторые решения пришлось менять. Так, мы не смогли добиться достаточной надежности от Apache Ignite и заменили его на сочетание Apache Cassandra, Apache Kafka и Apache Flink. Как ни странно, решение с большим количеством компонентов в итоге оказалось и проще, и надежнее. Подробнее о нем можно прочитать тут.

Заключение

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

Подробнее..

Про outsource и product компании

10.04.2021 14:17:23 | Автор: admin

Всем привет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробнее..

Перевод Нет Jira нет проблемы

11.04.2021 12:12:58 | Автор: admin

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

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


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

Но вот что примечательно: Jira преподносит себя как "рабочий инструмент номер один для гибких команд". Гибких? Хм-мм... Если для управления Jira нужен особый человек или даже целая аутсорсинговая компания, о какой гибкости можно говорить?

Давайте разберёмся, что вообще означает термин "гибкий" (Agile) и почему про него все сегодня говорят?

Последовательная разработка

Сегодня только и разговоров, что про методику Agile, как раньше про методику Waterfall. Впервые каскадная методика Waterfall была описана Уинстоном Ройсом в статье, опубликованной в 1970 году. Хотя термин Waterfall (каскад) не был употреблён в статье ни разу, описание метода напомнило многим каскадную схему:

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

Основная идея методики: любое планирование процессов разработки программного обеспечения должно осуществляться заранее, после чего должны выполняться последовательные шаги по созданию и поставке программного обеспечения. Данная концепция отлично вписывается в старые идеи научных методов управления, заложенные Фредериком Уинслоу Тейлором ещё в 1911 году. Если опустить детали, его идея состоит в следующем: организацию работ нельзя доверять исполнителям, нужна отдельная группа людей группа организаторов процесса, которая разработает последовательность действий, после чего безукоснительное выполнение таких действий поручается исполнителям.

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

Встреча в Сноубэрд

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

Это хорошо понимала группа разработчиков, собравшихся на горнолыжном курорте Сноубэрд в США в 2001 году. Они согласились с тем, что при изменении требований процесс разработки пойдет насмарку, а, так как препятствовать изменению требований невозможно, любая используемая методика управления процессом изначально обречена на провал. Так как же быть? Выход подсказал Александр Великий, разрубивший некогда Гордиев узел.

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

Изменение требований на поздних этапах является конкурентным преимуществом

-Мэри Поппендик

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

Основные положения манифеста:

  • Люди и взаимодействие важнее процессов и инструментов.

  • Работающий продукт важнее исчерпывающей документации.

  • Сотрудничество с заказчиком важнее согласования условий контракта.

  • Готовность к изменениям важнее следования первоначальному плану.

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

Что произошло?

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

Корень зла, согласно прагматическому замечанию Дэйва Томаса, кроется в том, что слово agile прилагательное, превратилось в Agile (собственное) существительное. Существительные продаются лучше, чем прилагательные, и даже возник "Промышленный комплекс Agile", приторговывающий маркой "Agile".

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

Если идея гибкости возникла в результате признания того факта, что мы не можем предвидеть, как именно могут измениться требования, то единого решения (процесса), которое подошло бы для всех возможных сред, не может быть просто по определению. "Agile-эксперты" навязывают нам определённый процесс, и такое состояние Мартин Фаулер называет неприкрытой пародией на "гибкость".

Как же так, вообще без процесса?

Но нужен же какой-то процесс, разве нет? Нужен, но какой? Да очень простой использовать всё, что работает! Но как узнать, будет ли он работать? Тут следует применить эвристический подход.

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

Инструменты

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

Инструмент, подходящий под это описание и имеющийся в каждом офисе, уже имеется!

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

Что не так с Jira?

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

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

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

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

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

Другие профессии и курсы
Подробнее..

Мой МТС. Продуктовая трансформация

12.04.2021 18:13:34 | Автор: admin
Всем привет! Мы продуктовая команда Мой МТС, занимаемся разработкой основного мобильного приложения компании МТС (iOS/Android) и сайта mts.ru. Месячная аудитория активных пользователей (MAU) на всех платформах свыше 23 млн. пользователей.

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

До трансформации

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

На начало 2020 года команда продукта Мой МТС состояла из 63 человек, которые были организованы следующим образом:



Разработка велась по зачаточному Scrum'у с двухнедельными итерациями и основными командными ритуалами. Однако, как заметит внимательный читатель, на схеме отсутствуют scrum master'а у нас это роль, которую выполнял и продолжает выполнять кто-то из членов feature team. Также была в наличии строгая изолированность Владельцев продукта и разработчиков. Мостиком между двумя мирами служили системные аналитики и технический лидер команды. Веб-разработкой полностью занимался подрядчик. Так совпало, что начало активной фазы избавления от внешних зависимостей началось одновременно с трансформацией.

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

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

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


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

  • Монолитные решения на всех платформах (iOS, Android, Web)
  • Полное отсутствие UI тестирования
  • Хаотичный процесс проверки pull request'ов без SLA


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

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


Цели трансформации

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

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

  • Общая прозрачность работы команды на всех уровнях понимание процессов и артефактов команды, в широком смысле этого слова, всеми сотрудниками, которым это может быть нужно, начиная с самих членов команды и заканчивая Советом директоров компании.
  • Уменьшение показателя Time-to-Market путем поиска и устранения узких мест в рабочем процессе и изменения подхода к работе в целом.


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

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


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

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


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

Трансформация

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

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

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

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

По итогам Квартального планирования мы получаем перечень задач, которые:

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

После окончания процесса Квартального планирования мы продолжаем регулярную синхронизацию по задачам на PO sync (еженедельная встреча Product Owner'ов и Chief Product Owner'а, технических лидеров, скрам-мастеров). Там же обсуждаем прогресс в достижении целей: если есть новые вводные или вскрылись не найденные ранее риски у нас есть возможность узнать об этом и повлиять как можно раньше.

Помимо Квартального планирования и PO sync, у нас в Мой МТС прижилась традиция проведения ежедневных чек-инов команды трансформации. В эту команду входят: CPO, технические лидеры, скрам-мастера. Иногда туда приглашаем и других участников, если того требует задача. Как уже говорилось, мы встречаемся этим составом ежедневно в конце рабочего дня, на 15-45 минут, обсуждаем и решаем вопросы, связанные с кадровыми изменениями, отзывами пользователей, новыми инициативами (например, перезапуск Discovery процесса, но об этом в следующих статьях), инициативами от членов команды и т.д. Крайне редко на чек-инах рассматриваются проблемы какой-то конкретной фичи, так как это более низкоуровневая повестка.

В силу размера компании нам не удалось внедрить новый подход везде и сразу, что привело к рассинхронизации при запуске нового механизма планирования у разных направления B2C, B2B и IT платформы.

Если говорить о структуре команды, то после трансформации продуктовая команда Мой МТС стала выглядеть следующим образом:



Разумеется, переход к новой структуре был поэтапным, нужно было нанять большое количество сотрудников и постепенно формировать новые команды. К сожалению, бурный рост не мог не сказаться на текучке кадров, и отток в 2020 году был самым большим за последние 4 года. Однако если рассмотреть последние месяцы 2020, когда найм по большей части был уже завершен, то ситуация заметно выправилась. Если говорить о цифрах, то в 2020 году текучка составила 30%, а в предыдущие годы (2018-2019) держалась на уровне 18%.

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

  • Основным изменением стал переход на юниты обособленные scrum команды, состоящие из технических специалистов, дизайнера и владельца продукта.
    Юниты собираются вокруг направлений бизнеса (например, фиксированная связь, финтех и так далее). В теории, подобная трансформация должна была привести к большей вовлеченности всех участников команды в специфику своих направлений и более качественной проработке продуктовых гипотез.
  • В команде продукта появились выделенные scrum-мастера. Они выполняют важные функции:
    • коррекция процесса трансформации
    • консультирование по вопросам Agile
    • связующую функцию с корпоративным центром продуктовой культуры.
  • Выделенная команда автоматизации UI тестирования.
    Значительный рост количества команд привел быстрому развитию приложения, вместе с которым также стремительно увеличивается количество тест-кейсов в регрессе. На данный момент автоматизировано 25% основных сценариев.
  • Мы начали активно работать в направлении перехода на In House разработку WEB.
    Процесс оказался значительно сложнее, чем в случае с мобильным приложением, в силу исторического и юридического наследия. Также ожидания бизнеса не позволили замедлить или остановить разработку нового функционала.
  • В 2021 году планируем провести эксперимент по созданию гибридных команд app+web.


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

Результаты

Если формально подводить итоги трансформации, то поставленные цели были достигнуты:
1. Процесс стал прозрачным для всех
2. Time-to-market сокращен в 1,5 раза

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

  • Излишняя прозрачность может быть вредной
    Применимо в случае, например, когда у стейкхолдеров есть некий технический бэкграунд (или они так думают) и они пытаются, экстраполируя свой старый опыт, активно влиять на рабочие процессы команды.Стоит отметить, что прозрачность планирования в полной мере не была достигнута. Квартальное планирование сейчас запущено параллельно на различных срезах (B2C, B2B, платформы), хотя остро стоит потребность в синхронизации.
  • Абсолютные значения показателей в вакууме
    Нам, конечно, удалось уменьшить time-to-market, но параллельно с трансформацией активно улучшались и подходы к работе владельцев продукта. Это привело к уменьшению среднего размера задачи и ускорило скорость доставки инкремента до пользователя. Даже не смотря на оговорки, подобный результат для нас очень ценен: отказ от больших и толстых задач, которые становятся неактуальными за время доставки до пользователей, является огромным плюсом. Также за прошедший год был сделан очень мощный рывок в работе с техническим долгом. Изолированные команды требуют по возможности изолированных песочниц в коде, поэтому модульность приложения стала основным техническим вектором для нас наравне с автоматизацией тестирования.


Новые проблемы

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

Также раньше мы очень большое внимание уделяли детальной проработке всех требований к фиче до старта разработки. Основные недостатки такого подхода это сужение пропускной способности всей команды и слишком тепличные условия для разработчиков и тестировщиков. В юнитах уже на первых порах стало видно, что старый подход к ТЗ не работает и нужно что-то менять аналитик не успевал готовить проработанные задачи. Для решения этой проблемы мы разделили ТЗ на две части must have для старта разработки и всё остальное. Этот подход несколько снял напряжение, но не закрыл все вопросы, поэтому дальнейшие проверки различных гипотез дело времени.

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

Планы

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

  • Вся разработка должна быть In House. На наш взгляд, это аксиома, аутсорсинг всегда непрозрачно и почти всегда неуправляемо.
  • Техническое развитие продукта
    • автоматические UI тесты для снятия лишней нагрузки с unit'ов при подготовке релизов
    • единый интеграционный backend для снижения затрат на подключения к другим системам ландшафта компании
    • дальнейшее развитие модульности приложения для упрощения работы структуры в целом. Для ускорения и стабилизации этого процесса мы планируем создать выделенную команду развития платформ.
  • Автоматизация сбора различных метрик работы unit'ов и продуктовой команды целиком.
  • Создание кросс-команды, в которую будет входить полный спектр специалистов для реализации функционала в app и web части нашего продукта.


Авторы Артем Андреев, Наталья Егорова, Алексей Кретов
Подробнее..

Основные проблемы в командах разработки и их решения

12.04.2021 20:16:10 | Автор: admin

Для будущих студентов курса "Product Manager IT-проектов" и всех интересующихся темой управления командой подготовили статью, автором которой является Сергей Колосков.

Также приглашаем всех желающих посмотреть открытый демо-урок Как продакт-менеджеру найти метрику роста и свести Unit-экономику?
За 1,5 часа на примерах реальных продуктов вы узнаете:
- почему успех продакт-менеджера это рост главной метрики продукта;
- как определить метрику роста;
- как построить аналитику и продукт вокруг метрики роста;
- научитесь расчету unit-экономики, как это делают продакт-менеджеры;
- узнаете, что может сделать продакт-менеджер для улучшения unit-экономики.


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

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

Проблема 1: Много идей и разговоров, работа движется медленно

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

Диагноз: в команде нет людей на две роли:

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

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

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

Проблема 2: Ступор при проблемах и затруднениях

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

Диагноз: не хватает ролей, приносящих новые идеи. За них отвечают две роли Генератор и Исследователь ресурсов, и они совсем разные:

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

  • Исследователь не генерит идеи. Но он много читает, активно общается и приносит новые идеи из внешнего мира: новые технологии, которые хорошо бы применить.

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

Проблема 3: Бесконечные споры между конкурирующими идеями

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

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

Лечение: развести Генераторов по зонам ответственности, или переключить одного из них в альтернативную роль, если она есть.

Проблема 4: Реализация сложных идей процесс, не результат

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

Диагноз: идеи от Генератора принимаются без рефлексии.

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

Проблема 5: Паралич принятия решений

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

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

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

Шейпер это более традиционный харизматичный руководитель, который активно и жестко ведет команду к принятым целям по выбранному им пути: Идем туда!

Лечение: внешнее руководство в точках принятия решений. Когда этот процесс налажен, неожиданностей почти не бывает.

Проблема 6: Слишком уверенный лидер

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

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

Проблема 7: Непродуктивная команда звезд

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

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

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

Лечение: Команде звезд нужен опытный руководитель-координатор, принимающий решения, потому что кто-то должен быть арбитром.

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

Проблема 8: Некому завершать работу

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

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

Педант (Completer Finisher) доводит дело до конца. Перфекционист, для которого главное качество и детали, а сроки могут подождать. Но без него оставшиеся 20% проекта никому не интересны.

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

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

Проблема 9: Нет сотрудничества

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

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

Душа команды (Team Worker) ненавязчиво налаживает отношения в команде, сглаживает углы и не участвует явно в управлении.

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

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

Момент 1: Пригодность и приемлемость

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

  • Пригодные и приемлемые им работа скучна, это просто ступенька карьеры.

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

  • Неприемлемые, но пригодные проблемные. Работу делают, но в команде из-за них возникают трения.

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

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

При формировании команды:

  • Нужны идеи, исполнители и организаторы.

  • Нужен хотя бы один (а лучше несколько) Работников компании и желателен один Педант.

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

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

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

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

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

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

Момент 2: Состав сбалансированной команды:

  • Руководитель Координатор, умеющий работать с талантливыми, но зачастую трудными участниками;

  • Один сильный Генератор;

При этом хорошим будем следующее распределение умственных способностей:

  • умный Генератор;

  • еще один умный не-Генератор, который ему оппонирует;

  • умный Координатор;

  • остальные чуть ниже среднего уровня.

Момент 3: Размер команды

Оптимальный размер команды 5-7 человек:

  • Ни 5, ни 7 человек не проигрывают и не выигрывают;

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

  • 4 человека могут быть успешны, если представлены все роли. Но в этом случае у команды нет резерва;

  • В команде от 10 человек неизбежно появляется ядро из 2-4 человек, принимающих решения и люди без включения в него.

Момент 4: Команды-победительницы

  • Смешанные сбалансированные команды, где представлены все роли.

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

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

  • Команды типа Аполлон (команды звезд): острый ум, ресурсы и таланты, но и большие сложности в их применении. Ключ к успеху хороший Координатор. Для сложных проектов такие команды особенно хороши, но нужно внимательно выбирать руководителя проекта.


Узнать подробнее о курсе "Product Manager IT-проектов"

Смотреть открытый демо-урок Как продакт-менеджеру найти метрику роста и свести Unit-экономику?

Подробнее..

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

15.04.2021 12:10:33 | Автор: admin

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

Идея GaaS Game as a Service неразрывно связана с понятием MMO. Именно по этому принципу мы оперируем своим мобильным PvP-шутером War Robots: такие игры с обновлениями получают постоянный поток нового контента и фичей на основе обратной связи с комьюнити. Это позволяет игре оперативно учитывать пожелания игроков и задавать новые тренды. В то же время модель GaaS усложняет внедрение в игру глобальных изменений, таких как ремастеринг графики ведь продукт не прекращает жить своей жизнью, пока вы год готовите обновление. Тем не менее, такие изменения необходимы, когда речь идет об играх-долгожителях.

War Robots исполнилось семь лет. Это немало и для большого ПК-проекта, а в случае мобилок и вовсе ломает представления о типичной продолжительности их жизни. Когда игра только вышла, рынок был наводнен match 3 и фермами, и входить на него с mid-core шутером было весьма рисково. Но вот мы здесь: рынок давно изменился, а War Robots все еще остается лидером в своем сегменте.

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

Ремастер фича или проект со своей командой?

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

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

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

В результате удалось убедить руководство студии и инициировать War Robots Remastered как отдельный проект со своей командой и целью:

Привлечь новую аудиторию к продукту War Robots, вернуть старую и повысить вовлечение текущей базы игроков. Для этого подготовить Remastered-версию продукта и раскатать релиз в продакшн на мобильных платформах App Store and Google Play до конца Q3 2020.

С целью проекта определились. Можно начинать собирать команду и приступать к оценке скоупа работ.

Как оценить объем работы, которую раньше никто не делал

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

Почему?Нельзя из старых технологий выжать крутую картинку на высоких FPS. Чтобы сделать level-up продукта, необходимо совершить апгрейд технологической базы. Невозможно создавать новых мехов с текстурами высокого разрешения и кучей полигонов на старой базе: ведь робот постоянно передвигается, ведет бой, на карте их 12 по 6 в каждой из соперничающих команд, и девайс должен просчитывать все их действия, эффекты и партиклы сражения. Если делать так, как описано выше, на выходе будет очень низкий фреймрейт даже на топовых девайсах то же самое, как если попытаться запустить на GeForce GTX 750 игру 2020 года.

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

Чтобы при ремастеринге меха не создавать трех разных роботов по одному на каждый пресет качества, нужно было изменить пайплайн, с помощью которого роботов в HD-качестве просто даунскейлить до MD и LD. А ведь таких роботов у нас 81 штука, не говоря уже дополнительно о 109 пушках и 83 элементах снаряжения.Мы хотим, чтобы наши игроки могли продолжить играть в War Robots а для этого нужно, чтобы на их текущих девайсах игра выглядела круто, и не было сильной просадки FPS. Мы довольно быстро стали понимать, что для этого нам необходим технологический стек, тянущий на AAA.

Так выглядели скриншоты Work in ProgressТак выглядели скриншоты Work in Progress

В результате нам нужно было проделать следующее:

  • Создание трех пресетов качества: LD низкое качество для low-end девайсов, MD среднее, HD высокое;

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

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

  • Освещение на старых картах: обновление технологий освещения и тюнинг оставшихся карт;

  • Оптимизация UI: рефакторинг UI-ассетов, интеграция упрощенных UI шейдеров;

  • Новые атласы текстур: рефакторинг атласов, реорганизация директорий в проекте;

  • Новые визуальные эффекты: создание новых VFX для пушек, мехов и карт, разные эффекты для разных пресетов качества; для VFX еще и новый движок;

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

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

Как оценить время, которое займет выбранный объем работ

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

Можно ли оценить весь ремастер на старте?

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

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

Поэтому действуем по следующей схеме:

  • Решаем, что мы хотим сделать и что получить на выходе;

  • Декомпозируем;

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

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

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

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

Какое решение? Идти путем итераций.

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

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

Риск-менеджмент, или как вырабатывать меры раньше, чем придется тушить пожары

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

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

  • уклонению;

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

  • передаче третьей стороне;

  • принятию (активному или пассивному).

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

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

Что делать, если со своим объемом работ вы не вписываетесь в заданный дедлайн

Легко попасть в ситуацию, когда планы монументальные, хотелок много, а времени мало. Что же делать в таком случае?

Например, учиться от чего-то отказываться.

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

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

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

Установка правильного контекста. Как постоянно менять план и не шокировать этим команду

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

Так, мы не планировали делать Ultra Low-пресет качества, но были вынуждены к нему прибегнуть, потому что тесты показали, что текущие лоу-энд девайсы не тянут даже LD. Новый пресет качества отдельная работа. Невозможно впихнуть ее в те же сроки, что и раньше. Что делать в таких случаях? Мы делаем этот пресет, но отказываемся от какой-то другой работы.Нужно изначально быть готовым к тому, что при всей точности оценок а это мало достижимо со 100% точностью, границы между обязанностями двух команд одного продукта могут размыться и требовать постоянного уточнения. При этом изменения в roadmap одного проекта будут влиять на roadmap другого.

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

Подводя итоги: что стоит учитывать на этапе предпродакшена

  • Необходимо закладывать буфер на неизвестность на старте.

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

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

  • Управлять рисками на стадии препрода еще при инициации проекта и продолжать на последующих этапах продакшн.

  • Стоит выделить одного ответственного человека за каждый фронт работ.

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

Автор материала Дмитрий Осипов, ведущий руководитель проектов War Robots и War Robots Remastered

Подробнее..

Встречи планирования разработки в пандемию, или Как устроить электро PIP

15.04.2021 14:13:15 | Автор: admin
Сегодня мне хотелось бы с помощью моих коллег Agile-коучей Ани Родионовой, Макса Зотова и владельца продукта в Трайбе Розничное взыскание и урегулирование Свята Божухина рассказать о практике применения интересного инструмента. Итак, речь пойдёт о Program Increment Planning Meeting aka PI Planning.

Это метод планирования из SAFe (Scaled Agile Framework) гибкого фреймворка для крупных компаний. Ну, знаете, это когда люди стоят у стены, оклеенной стикерами, лепят всякие ниточки от одного стикера к другому, но при этом в городе не орудует маньяк.

Ниже пример места встречи одной из команд для PI в Сбере (обратите внимание на ту самую стену на заднем плане):

image

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

С чего началось


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

Вот так выглядит SAFe, и скромную часть в нём занимает PI:

image

Вот что должны сделать разные участники, чтобы планирование прошло успешно:

image

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

Scrum-мастерам поручили подготовить все шаблоны флипов (флипчартов). В онлайне они трансформировались в таблички на Confluence в специальном пространстве для совместной работы.

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

Группа фасилитаторов следила за тем, чтобы все шаблоны в Confluence были подготовлены и всё логистически готово.

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

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

Сама история почти не поменялась: если раньше были физические флипчарты, то теперь они стали виртуальными.

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

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

image

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

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

image

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

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

Процесс


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

Дальше идёт работа команд:

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

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

В электронном виде стало удобнее: появилась чёткая структура, добавилась лучшая сохранность артефактов. Каждая задача ставится в Confluence.

В среднем из запланированного делается по факту 7080 %. Это очень качественный показатель.

Инвестиция в будущее


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

Вот так, если вкратце про PI Planning. Если хотите больше подробностей, то можно посмотреть выступление коллег тут.
Подробнее..

Пожарный не из Чикаго как тушить огонь в ИТ-проектах

15.04.2021 16:11:54 | Автор: admin

Привет, Хабр! Меня зовут Александр. 17 лет в КРОК. В основном занимаюсь разработкой и внедрением заказного ПО, хранилищ данных, решений Big Data для бизнеса и госсектора. Начинал консультантом по внедрению и последние 11 лет работаю менеджером крупных комплексных проектов. А еще я немного пожарный, потому что регулярно помогаю коллегам тушить проектный огонь.

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

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

Про коллаборацию заказчика и соисполнителей

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

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

Про коллаборацию заказчика и соисполнителей еще раз

Годы работы в проектах ЕМИАС преподносили нам очень разные вызовы в 2013 у нас была команда внедрения с 700+ консультантами во всех амбулаторно-поликлинических учреждениях Москвы. В 2018 нам надо было найти 100+ консультантов для внедрения лабораторного сервиса ЕМИАС это два месяца собеседований нон-стоп. Но оно того стоило!

Как справились с огнем? Тут, опять же, заказчик помогал в согласовании плана внедрения на стороне объектов внедрения с постепенным наращиванием оборотов и административным ресурсом с оповещением поликлиник, лабораторий. Это еще раз подтверждает тезис необходимости совместной мощной команды не только со стороны исполнителя, но и заказчика. В сложных проектах верно выстроенный процесс взаимодействия и коммуникаций (читай синергия команд обеих сторон процесса) путь к успеху. И вторая мораль этой истории не бояться огня. Глаза боятся (осознав, сколько нужно консультантов и в какой срок, задача казалась нерешаемой в принципе), а руки взяли и сделали! Хоть и собеседования проводили всем миром.

Про ток, или Как снять напряженность клиента

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

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

Про важность работы напрямую с бизнес-заказчиком и решение именно его задачи

Несколько похожая, но вместе с тем иная ситуация была у меня и в другом проекте, где мы для одного из банков делали Big Data систему для построения профиля клиента и оценки рисков при выдаче кредита. В момент подключения меня в проект была не первая фаза, а я не первым РП на стороне исполнителя. Ситуация была схожа с прошлым кейсом непрозрачный процесс разработки для заказчика усугублялась отсутствием четкого ТЗ, ибо такого рода систем в банке, да и на рынке, в то время по сути еще никто не делал. Были первые ласточки в банке Т и банке А, однако готовых решений (да еще на open source) не было. По сути строили с нуля, склеивая кусочный опыт в комплексное решение, попутно синхронизируясь с заказчиком. И еще требования бизнес-заказчиков ловко и резко менялись по ходу представления.

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

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

Про не всемогущий agile

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

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

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

Про опытных пожарных

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

Мало огня?

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

Этот кейс был особенно сложен еще и тем, что по ходу проекта (это более 1,5 лет) многие задачи делались от потребности заказчика в моменте, без оглядки на ТЗ. К концу проекта оказалось, что сделана гигантская работа, но не по ТЗ. Хотя многое реально потеряло актуальность за время проекта. А подписались-то мы под ТЗ. И особенности конкретного заказчика были таковы, что невыполненные требования ТЗ к принимаемой системе это путь под откос.

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

Противопожарные меры

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

Со стороны исполнителя важные и проблемные места, которые могут привести к пожару:

1. Отсутствие полной команды управления исполнителя. Для КРОК это два менеджера РП и технический менеджер ТМ, а для комплексных проектов с несколькими командами РП и несколько ТМ;

2. Проблемы коммуникаций не пускают к функциональным заказчикам;

3. Проблемы коммуникаций между смежными командами внутри исполнителя (тоже бывает не так уж редко), и, конечно, с командами заказчика;

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

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

Со стороны клиента:

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

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

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

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

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

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

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

Другим классным инструментом, которым в КРОК по мере возможности пользуюсь тимбилдинги. И это вовсе необязательно замороченное мероприятие типа командной сдачи норм ГТО (хотя и такое было, и это было огонь!). Тут можно и просто собрать команду в неформальной обстановке, пообщаться, поиграть в дженгу и киккер и просто снять таким образом напряжение зума, тимса, вебекса и бесконечных созвонов-созвонов-созвонов Это работает! Я проверил!

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

Вместо заключения

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

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

Подробнее..

Практика создания единого шаблона проектов на базе Azure DevOps (TFS)

16.04.2021 08:17:32 | Автор: admin

В одной из прошлых статей мы писали, как всей компанией перешли на единый трекер на базе Azure DevOps (TFS). Это позволило нам создать единый свод правил для ведения проектов. Рассказываем, как наш проектный офис разработал логику, по которой сейчас работают все наши команды.

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

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

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

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

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

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

Что входит в шаблон проекта True Engineering

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

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

Здесь важным критерием является конечность эпика во времени, то есть достижимость конкретной цели. Хороший пример эпика Автоматизация тестирования на проекте.

Под ними Feature, эти элементы разрабатываются за 1-3 спринта). Одна Feature один бизнес-сценарий. Например, оформление командировок.

Ещё одним уровнем ниже PBI (Product Backlog Item, единица поставки), они представляют собой отдельный кейс в рамках сценария. Подготовка заявки на командировку, согласование поступающих заявок, загрузка чеков для авансового отчёта это PBI. Они разделяются на Task-и, атомарные единицы работы, которая назначается на исполнителя и не занимает больше 8 часов.

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

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

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

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

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

3. Поддержка планирования ресурсов и времени. Мы внедрили во всех командах три метрики для контроля трудозатрат:

  • Первоначальная оценка времени на разработку

  • Реально зарепорченное время

  • Остаток времени

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

Технические возможности шаблона в Azure DevOps

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

Плагин TFS Aggregator. Этот инструмент подключается к проекту и позволяет автоматические контролировать движение статусов Task-ов и по этим данным отслеживать состояние их родительских PBI. В результате мы можем написать единые правила для трекера заказчика и отправлять ему оповещения о статусах релизов, комментариев к задачам и т.д. Эта функция используется для автоматического сбора Release Notes, уведомления заказчикам о поставках фич, как мы рассказывали в материале про Release Notes.

Интеграция с OLAP-кубом. Эта функциональность отвечает за анализ трудозатрат, статусов задач, контроль Time-to-Market, прочих проектных показателей. Раньше мы использовали куб для контроля показателей внутри проектов. Когда у нас появилась единая система координат, стало возможным делать сквозную аналитику по всем командам сразу мы знаем, что во всех проектах действуют одни и те же измерения с одними и теми же смыслами.

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

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

Куда двигаемся дальше

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

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

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

Подробнее..

Перевод 13типовразработчиков,скемяработал

17.04.2021 10:20:32 | Автор: admin

Вы можете любить или ненавидеть их, но вы не можете игнорировать их.

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

В этой статье я перечислю некоторые типы этих разработчиков.

1.Продавецдыма

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

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

2.Мультизадачныйразработчик

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

3.Специалистссертификатами

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

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

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

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

Конечно, сертификаты или степень в образовании это прекрасно, но только если это подтверждено реальным опытом, иначе вы становитесь разработчиком-теоретиком.

4.Неряшливыйразработчик

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

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

Увасможетбытьмногоключей,чтобыраспознатьнерях:

  • Упорядоченылиихзаметки?

  • Записываютлиони,чтобынезабыть?

  • Приведёнлиихрабочийстолвпорядок?

5.Разработчик-теоретик

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

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

6.Рядовойразработчик

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

7.Боязливыйразработчик

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

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

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

8.Универсальныйразработчик

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

9.Нарцисс

Обычно имеют огромное эго и плохие командные навыки.

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

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

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

10.Одержимыйвсемразработчик

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

11.Единорог

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

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

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

12.Быстрыйразработчик

Они склонны заканчивать всё быстро, но берут новую задачу без 100-процентного закрытия предыдущей.

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

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

13.Разработчик,которыйвсегдахочетпомочь

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

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

Заключение

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

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

Подробнее..

3 пути к возрождению организации

19.04.2021 00:19:54 | Автор: admin

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

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

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

Начнем со знакомством с философией трех путей:

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

  • Второй Путь - это движение по дороге улучшений за счет построения циклов обратной связи.

  • Третий Путь пропагандирует культуру постоянного эксперимента. Движение дорогой проб и ошибок позволяет организации расти и развиваться.

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

О них дальше и поговорим.

Визуализируйте всю работу

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

  • бизнес проекты - тип работы, которая создает ценность для конечного пользователя и/или конкурентное преимущество организации;

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

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

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

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

Выявляйте ограничения

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

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

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

Устраняйте ограничения

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

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

Устраняйте движение против потока

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

Наладьте обратную связь

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

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

Экспериментируйте

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

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


Подробнее..

Категории

Последние комментарии

© 2006-2021, personeltest.ru