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

Команда

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

18.05.2021 18:11:11 | Автор: admin

Привет! Я Илья Тананаев. Руковожу отделом первой линии техподдержки в ITSumma. И хочу поделиться опытом, как из поиска решения проблемы пропущенных чатиков с клиентами мы построили кузницу кадров. Успешно успевая при этом обрабатывать 3k+ клиентских обращений в сутки.

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

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

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

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

ITSumma начиналась с того, что мы помогали сайтам выдерживать нагрузки и не падать при любых обстоятельствах. Сейчас, спустя 13 лет после основания компании, техподдержка уже далеко не единственное направление нашей работы, но по-прежнему существенное. У нас большой отдел эксплуатации, который следит за инфраструктурой клиентов и реагирует на инциденты 24/7 с SLA в 15 минут.

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

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

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

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

Итерации решения

Сначала первая линия не работала 24/7, да и в принципе, не сразу взяла на себя работу с вообще всеми клиентами. Тем не менее, когда мы вышли на две стабильные смены с 7 утра по Москве (с 12 по Иркутску наш стандартный режим для большинства сотрудников) и с 11 по Москве в будние дни, это уже сильно сняло нагрузку с админов и помогло упорядочить работу. Мы поняли, что первая линия действительно полезна, а от админов круглосуточной техподдержки поступил запрос на работу первой линии не только в дневное время.

В 2019-м мы ввели еще смены для подстраховки на время пиковой нагрузки по будням с 10 утра по Москве. А позже, проанализировав ситуацию, решили, что нужно переводить первую линию на 24/7 чтобы помогать техподдержке всё время.

Итоги первого года работы первой линии:

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

  • Ответственным за SLA стал не только отдел эксплуатации, но и первая линия поддержки.

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

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

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

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

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

Расписание для людей

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

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

Мы попробовали разные варианты: 8- и 12-часовые смены, только дневные и только ночные, вперемешку и т.д. Вот что получилось:

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

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

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

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

Развитие специалистов первой линии поддержки

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

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

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

Таско-дни или командировки в другие отделы

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

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

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

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

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

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

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

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

Направления для командирования сотрудников первой линии поддержки такие:

  • документация;

  • мониторинг;

  • эксплуатация;

  • дежурства второй линии;

  • аккаунтинг;

  • и даже разработка.

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

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

Онбординг-курсы

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

Документирование нашей работы прошло довольно стандартный путь:

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

  • На первой итерации по улучшению я выделил время и постарался её систематизировать стало чуть лучше, но еще не достаточно.

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

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

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

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

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

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

При проверке скрипта на корректность перед запуском на какие критерии обращаем внимание?

1. block for commit.

2. block for delay.

3. PS/SQL file successfully completed.

4. exit.

5. set auto commit off.

6. current schema.

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

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

Можем ли мы изменять категорию задач вручную в созданной задаче? Если да, то где?

a. Можем, но аккуратно в Состояние.

b. Нет

c. Можем. В созданной задаче в правой колонке. Там, где Категория

d. Неее. Такого быть не может

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

Как видите, это не похоже на строгую сертификацию. Это просто еще один способ помочь новому сотруднику усвоить много информации в короткие сроки.

После доработки документации онбординг курсы это лучшие инвестиции в развитие отдела.

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

  • Сэкономили время опытных специалистов на онбординг новичков.

  • Уберегли главного наставника новичков от выгорания.

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

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

Результаты

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

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

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

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

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

Takeaways

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

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

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

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

Подробнее..

Сказ о том, как команда IT animals в Северо-Западном хабе Цифровой прорыв выиграла

19.03.2021 12:22:16 | Автор: admin

В прошлом году я случайно наткнулась на сайт #ЦифровойПрорыв и шутки ради отправила ссылку тимлиду нашей команды разработки: смотри, поучаствуем? Мы как раз успевали на последний региональный Северо-Западный хаб.

Из положения о конкурсе:

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

Всего в рамках Конкурса планировалось проведение 8 окружных онлайнхакатонов, которые завершились Финалом.

Принцип Парето

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

Команду собрали из коллег: тимлид/архитектор/питчер Илья Шумилов, 2 full stack Дмитрий Николаев и Кирилл Петров, аналитик/тестировщик Марина Никулина. Так появилась команда IT animals.

А что же дальше?

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

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

В пятницу вечером мы остались после работы в офисе и приступили к решению.

Формулировка кейса и наше видение решения

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

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

Стек технологий: php7, apache, yii2, postgresql, yii2 queue, ГАР.

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

Что происходило на самом деле:

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

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

Что очень понравилось: были четкие требования по структуре презентации и питча.

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

А потом наступило утро воскресенья. Сдать решение кейса надо было до 08:00 (МСК): я судорожно сохраняла презентацию в pdf, чтобы загрузить ее на сайт ЦП. 3 раза перепроверила, что загрузила верный файл. Ждем защиты.

За питчера у нас был тимлид Илья: 5 минут на презентацию и 3 минуты на вопросы.

Как толстовка большим кушем оказалась

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

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

Выплату обещали совершить в течение 90 рабочих дней так и случилось. Что вдвойне приятно обязанности налогового агента организаторы ЦП взяли полностью на себя, и сумма пришла уже за вычетом НДФЛ. Это сохранило много нервных клеток участников (ну мне точно).

Первая пятерка в рейтинге участников каждого кейса автоматически попадает в Финал конкурса Цифровой прорыв мы были из их числа. О нем расскажу позже.

Подробнее..

Как команда it-animals в финале Цифрового Прорыва выиграла

24.05.2021 16:18:49 | Автор: admin

Данная статья написана в соавторстве с тимлидом @Restlin

Выбор кейса и наше видение его решения

Изначально выбор пал на кейс МВД: Разработка автономного программного решения лингвистического анализа и преобразования в тексте лица повествования.

Формулировка кейса:

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

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

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

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

1) локальное решение, работающее без доступа в сеть;

2) интегрированные офисные пакеты посредством макросов.

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

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

Формулировка кейса:

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

Почему он? У нас было понимание как работать с электронной подписью на Open source решениях: OpenSSL. Пригодился опыт Ильи в разработке СЭД - он знал о существовании php библиотеки tcpdf для генерации файла pdf с возможностью встроить электронную подпись. Плюс на текущем проекте pirs.online мы уже копали эту тему, и оттого данной задачей заниматься было приятно вдвойне.

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

Панические атаки и ведро валерьянки

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

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

А что потом? Технические подробности

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

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

С точки зрения технической реализации функционал прототипа выглядел просто:

  • вход пользователя под одной из двух ролей: гость и администратор;

  • формирование обращения администратору (почте РФ);

  • рассмотрение обращения и формирование ответа;

  • можно прикрепить файлы к обращению и ответу;

  • создать сертификат пользователя в личном кабинете;

  • подписать файлы ответа электронной подписью;

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

  • проверить электронную подпись в обращении.

Структура базы данных прототипа уместилась всего в 3 таблицы, размещенных в PostgreSQL:

  1. user - таблица пользователей с реквизитами и типами;

  2. message - таблица обращений и ответов. По сути это переписка клиента и администратора;

  3. file - таблица файлов, прикрепленных к обращениям и ответам.

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

Для работы с электронными подписями мы решили использовать OpenSSL, как открытый стандарт де-факто по работе с электронными подписями.

Как и ожидалось библиотека очень мощная, но из коробки не поддерживает отечественные алгоритмы шифрования. Какое-то время ушло на интеграцию и настройку криптографического движка (libengine-gost-openssl 1.1) на алгоритмы ГОСТ, в частности ГОСТ-2012. Затем мы создали и настроили удостоверяющий центр.

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

Пилим прототип дальше

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

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

Создание сертификата пользователя:

exec("openssl req -nodes -newkey gost2012_512 -keyout $eSignPath/client.key -pkeyopt paramset:A -out $eSignPath/client.csr -subj \"/C=RU/ST=Udm/L=Izhevsk/O=IT/OU=animals/CN=user-{$user->id}\" -config $caPath/openssl.cnf ");

exec("openssl ca -engine gost -keyfile $caPath/ca.key -cert $caPath/ca.crt -in $eSignPath/client.csr -out $eSignPath/client.crt -batch -config $caPath/openssl.cnf 2>&1", $output);

где $eSignPath - путь до папки с ключами пользователей, а $caPath - путь до папки удостоверяющего центра.

Удаление сертификата пользователя:

exec("openssl ca -config $caPath/openssl.cnf -keyfile $caPath/ca.key -cert $caPath/ca.crt -revoke $eSignPath/client.crt 2>&1", $output);

exec("openssl ca -gencrl -config $caPath/openssl.cnf -keyfile $caPath/ca.key -cert $caPath/ca.crt -out $caPath/crl.pem 2>&1", $output);

где $eSignPath - путь до папки с ключами пользователей, а $caPath - путь до папки удостоверяющего центра.

Подписание файла сертификатом пользователя:

exec("openssl smime -engine gost -sign -in $fp -out $fp.sig -nodetach -binary -signer $clientKeysPath/client.crt -inkey $clientKeysPath/client.key -outform SMIME 2>&1", $output);

где $fp - путь до файла, $clientKeysPath - путь до папки с ключами пользователя.

Проверка подписи файла:

$output = exec("openssl cms -engine gost -verify -in $sigPath -inform SMIME -CAfile $pathCA/ca.crt -out $fp -certsout $clientKeysPath/client.crt 2>&1");

где $fp - путь до файла, $clientKeysPath - путь до папки с ключами пользователя, $sigPath - путь до электронной подписи.

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

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

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

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

$fields = [

'r' => 'api/sign',

'filePath' => $tempdoc,

'userId' => $user->id,

];

$query = http_build_query($fields);

$ch = curl_init();

$host = \Yii::$app->params['apiHost'] ?? '';

curl_setopt($ch, CURLOPT_URL, $host . '/index.php?' . $query);

curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

$signature = curl_exec($ch);

/*if (empty($this->signature_data['extracerts'])) {

openssl_pkcs7_sign($tempdoc, $tempsign, $this->signature_data['signcert'], array($this->signature_data['privkey'], $this->signature_data['password']), array(), PKCS7_BINARY | PKCS7_DETACHED);

} else {

openssl_pkcs7_sign($tempdoc, $tempsign, $this->signature_data['signcert'], array($this->signature_data['privkey'], $this->signature_data['password']), array(), PKCS7_BINARY | PKCS7_DETACHED, $this->signature_data['extracerts']);

}*/

И все же мы успеваем в последний момент и к утру воскресенья прототип полностью работает!

Последний рывок и мы у цели

В середине дня воскресенья Илья подключается по Zoom к защите решения, жюри неумалимы, ну а мы ждем результатов.

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

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

Офтоп: мы победители! 750 тысяч на команду, Карл! 750 за 2 дня, Карл! А значит едем на грандфинал Цифрового прорыва в Москву!

Репозиторий нашего решения

Подробнее..

Корпоративные опросы всех бесят, но я знаю, как это исправить

01.12.2020 18:05:13 | Автор: admin


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

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

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

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

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

Откажитесь от почты


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

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

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

Правильно задавайте вопросы


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

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

Скомкано Развёрнуто
Тревожился? Как часто ты испытывал тревогу за задачи или проект?
Как тебе задачи? Ты получал удовольствие от задач?
Устал? Как часто ты чувствовал, что у тебя не осталось сил выполнять задачи?

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

Вот список вопросов, которые я задаю команде:

Как часто ты чувствовал, что у тебя закончились силы выполнять задачи?

  • Ни разу
  • Один раз в неделю
  • Два-три раза в неделю
  • Почти всю неделю

Ты получал удовольствие от задач?

  • Да
  • Скорее да
  • Задачи как задачи
  • Скорее нет
  • Нет

Как часто ты испытывал тревогу за задачи или проект?

  • Ни разу
  • Один раз
  • Два-три раза в неделю
  • Почти всю неделю

Сколько часов ты переработал? (сумма за неделю)

  • 0
  • До 2х
  • От 2х до 4х
  • От 4х до 8ми
  • От 8ми до 12ти
  • Более 12ти

Тебе понравился спринт?

  • Лучший спринт
  • Хороший спринт
  • Норм
  • Ну такое
  • Это провал


Одно время вместо вариантов ответов я просил дать оценку от 0 до 10, но это абсолютно плохая идея, не делайте так. Оценка цифрой очень относительна, ведь человек, который привык овертаймить, поставит от 4 до 7 баллов за тот же набор задач, за который обычный сотрудник смело ставит больше 8. Но ещё сложнее сделать выводы и обсуждать средние значения из таких данных.

Проанализируйте ответы


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





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




Бонус. Личная динамика


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



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



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

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

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

Agile в Сбере как понять, что происходит?

15.03.2021 10:06:02 | Автор: admin
image

В декабре 2020 мы провели Sbergile Talks (да, давно это было), нашу первую онлайн- конференцию про Agile в Сбере. Три потока, 31 доклад, спикеры из крупнейших отечественных и иностранных компаний, которые так или иначе связаны с Agile. Нас слушало порядка 10 тысяч человек. Я хочу пробежаться по основным моментам и рассказать, что же там было.

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

Так почему же Agile так интересен российскому рынку?

Agile в России


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

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

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

По нашему мнению, Agile это работающие практики, которые способны запустить процесс изменений в компании. А в бизнесе успешны те компании, которые готовы меняться и подстраиваться под запросы рынка.

Где смотреть доклады?


Стрим Организация.
Стрим Продукт.
Стрим Команда.
Обсуждение в чате.
Самые актуальные новости Sbergile в канале.

Какие доклады стоит посмотреть и почему?


В направлении Организация взгляд бизнеса на управление в целом.

  • В докладе Agile-трансформация Сбера Ксения Яшина рассказывает, как изменился подход в целом. Пример сейчас 100 тысяч pull-реквестов ежемесячно, а в начале 2020 года их было около 60 тысяч. И отправляют их в том числе сотрудники экосистемы.
  • Насколько эффективен процесс производства и поможет ли восьмирукий разработчик это как раз про полностью новый автоматизированный производственный процесс и единую среду разработки.
  • Agile #каквСбере для вашей компании про то, как можно внедрить такой же подход с нашей помощью.
  • Стандартизируй это! Как провести трансформацию и не стать новой Вавилонской башней главное помнить, любой стандарт это гипотеза и должен проверяться как гипотеза. Подробно рассказывается, как выглядит жизненный цикл стандарта от его разработки рабочей группой до утверждения. На выходе сокращение издержек в коммуникациях, отчётности, прозрачность и управляемость.
  • Трансформация розничного взыскания. От революции к эволюции Денис Кузнецов, директор дивизиона из Департамента по работе с проблемными активами, рассказывает, как их команда стала пионерами рынка. Свои слова подкрепляет крутыми кейсами. Например, ребята запустили продукты вроде электронного взаимодействия с ФССП, робота-коллектора, исполнительную надпись нотариуса. И стали первыми по бенчмаркам во взыскании в стране.
  • Shiftup Business Agility жизненный цикл бизнес-модели доклад Agile-коуча Янины Лашкевич основан на материалах последней работы Jurgen Appelo и более чем 15-летнем опыте в разработке продуктов и проектов в разных бизнес-моделях.
  • Мотивация внутри каждого из нас или как выпустить внутреннего профи здесь не будет ничего про пирамиду Маслоу, сложных терминов из психологии. Здесь подробный алгоритм, как повысить внутреннюю мотивацию и определение уровня выполнения потребностей. С отличными примерами.
  • Как стать вовлекающим лидером тут речь идёт про фасилитирующее лидерство. Про то, как правильно формировать и поддерживать группы, чтобы они эффективно шли к одной общей цели, как взаимодействовать друг с другом, распределять задачи, отслеживать прогресс и действовать по общим принципам.
  • Как не потерять контроль, когда в периметре 3000+ команд? точно не делать шаг назад в мир документов и согласований. Выход структурировать данные из систем, сделать понятные разрезы на всех уровнях. Понять, что контроль даёт свободу убедить в этом команду, дальше никакой ручной отчётности, только данные из систем.
  • PI Planning в условиях пандемии это история про модель планирования для больших компаний в период очень сложных изменений. Рассматривается методология, которая довольно редко используется на отечественном рынке.

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

  • Продуктовый офис. Как запустить конвейер проверки гипотез рассказывает Илья Забелин, управляющий директор, руководитель Продуктового офиса Сбера. Он более десяти лет (из них пять лет в Яндексе) занимается созданием, запуском и развитием своих и корпоративных продуктов в eНealth, ЕdТech, FinТech, E-СОМ. Илья показывает и рассказывает, как очень быстро проверять множество гипотез и как выстроить процессы в компании, способствующие этому.
  • Выстраивание системы управления клиентским опытом на примере корпоративных клиентов рассказывается о том, как искали причины возможного недовольства, потребительские инсайты и вообще оценивали качество.
  • И очень практически-полезный доклад Встраивание CX-исследований в жизненный цикл продукта если у вас ещё такого нет, то стоит присмотреться, это практический опыт.
  • Обучение Agile для лидеров если у вас в планах создать эффективную команду и управлять ею, а времени совсем в обрез. Денис Тучин, Agile-коуч, который вместе со своей командой обучил более 500 руководителей разного уровня, в деталях рассказывает, как организовать процесс, следить за ним по целям в Jira, как снизить time-to-market, не снижая или даже повышая качество продуктов.
  • Детство. Отрочество. Юность Agile-команды полезный доклад для молодых команд, неофитов Agile, джуниор-продактов. Ребята рассказывают, как разбирались с операционным процессом. По ходу можно сравнить реальный опыт с теорией, избежать ошибок, подсмотрев чужие, узнать, что всё, происходящее с вами, уже кто-то пережил. И выдохнуть.
  • 4 шага к эффективности команд никакой воды, только чистая польза. Рассказывается, как эффективно провести Agile-трансформацию в компании. С чего начать и как довести до конца. Если коротко ускорить поставку, добавить гибкости, выстроить приоритизацию через оценку, мониторить метрики.
  • СберБизнес. Как мы поменяли управление командами и сократили энтропию тут подробно говорится о капитанской модели изменений Коттера, а самое главное как её применять на практике. И ещё про то, как увеличить эффективность и результативность системы и дать ей возможность масштабироваться.
  • B2B Digital. Лицом к клиенту здесь можно найти ответ на вопрос Как пройти путь от продукта к клиенту?, начиная с фич, вывода в ПРОМ и заканчивая метрическим целеполаганием и влиянием на клиентский опыт.
  • Взлетают метрики, команда растёт втрое. Всё это за один год. Как не сойти с ума продакту? о том, как перестать работать без чёткой организации производственного процесса и научиться делегировать. Будут нужны дежурный спринта и дежурный релиза.
  • С ресурсами любой может: запуск продукта без необходимых средств, времени и плана история про правильную аналитику и оптимизацию приоритетов, ведущую в итоге к максимально быстрому выходу на MVP и его тестированию.

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

  • Школа Scrum-мастеров как элемент матрицы развития Scrum-мастера про то, как создавать внутри компании специалистов, которые подружат разработку и бизнес. Как разрешать конфликт, когда бизнес хочет продукт здесь и сейчас, а разработка хочет делать это правильно. И те же самые Scrum-мастера выступают не только посредниками между командами и заказчиками, но и помогают командам быть эффективнее.
  • Как команда Критические заболевания тестирование в два раза ускорила история изменений в процессе релиза, которые позволили за одну итерацию проходиться по основным болевым точкам.
  • Перезагрузка сознания legacy-команд это боль почти каждого в финансовой сфере, тем более с долгой историей.
  • Будни Scrum-мастера или как зажечь сердце команды без жертв Дарья Михеинко, лидер направления, Scrum-мастер, аналитик, рассказывает, про то, как важно настроить свой энергетический баланс, чтобы замотивировать команду. Как избежать рутины и максимально эффективно помогать команде, не выгорая.
  • Разделяй и властвуй. Опыт создания продуктов в малых группах разработки на своем примере ребята доказывают, как за два года можно пройти от двух поставок в ПРОМ до 47, выполнения более 100 задач и ускорения Т2М в 1,5 раза.
  • Развитие Scrum-мастеров после Школы Scrum-мастеров история о том, как вдвоём можно развивать 50 Scrum-мастеров и что из этого получается. Для Scrum-мастеров есть школа СМ, профессиональное сообщество СМ, гильдии СМ, конференция СМ, чаты для СМ. Так что без помощи не останетесь.
  • Как Scrum-мастер перевернул тестирование в команде с ног на голову реальные ситуации и новые командные практики.
  • Ускоряем процесс разработки по максимуму ребята научились выпускать больше релизов от 32 до 55 за год, сократили время от завершения тестирования до внедрения в ПРОМ.
  • Пройти путь Scrum-мастера без ошибок. Лайфхаки о вопросах, которые себе должен задавать хороший Scrum-мастер. Давайте спросим команду один из ключевых.
  • Результативность продуктовой команды. Есть ли прогресс? roadmap от усовершенствования системы оценки задач и планирования спринтов до количественного представления результативности участников команды. Путь от оформления описания и пошаговой инструкции с примерами в Confluence до оптимизации и усовершенствования.

Итог


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

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

Как я пробовал внедрять DDD. Тактические паттерны

10.06.2021 14:04:32 | Автор: admin

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


Поначалу мне попали в работу легаси проекты, архитектура которых была Transactional Script или Table Module. Модули требовали рефакторинга, решения тех.долгов, встал вопрос о целесообразности рефакторинга и альтернативных реализаций. Как инженер, я решил, что единственный верный шаг прокачать себя, а затем и команду, теоритически, а потом предпринимать стратегические шаги. Если с TS и TM архитектурами я был хорошо знаком, то шаблон Domain Model был знаком только в самых общих чертах по книге Мартина Фаулера. На фоне общения на конференциях, чтения матёрых книг про рефакторингу, SOLID, Agile, пришло понимание почему именно изучение подобных архитектур оправдано: в Enterprise есть смысл стремиться к максимально адаптируемому к изменениям ПО, а для доменной модели изменения требований стоят несравнимо дешевле в реализации. И меня напрягало, что как раз доменные модели я если и применяю, то понаитию, бессистемно, невежественно. Так началось моё знакомство с предметно-ориентированным проектированием.


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


Тактические паттерны


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


Доменная модель


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


  1. Абстрактная модель. Публичные интерфейсы модели, которые могут быть доступны в других слоях. Сами интерфейсы пишутся так, чтобы они наследовали интерфейсы из нашего Seedworks, что позволяет избежать зоопарка в различных проектах. Абстрактная модель первое с чего начинается любой сервис, т.к. содержит в себе ОБЩЕУПОТРЕБИМЙ ЯЗК.
  2. Реализация модели. Internal реализация агрегата, содержатся необходимые проверки, скрываются фабрики, бизнес-методы, утверждения и т.д.

Реализация агрегата


Команда рассматривала следующие способы реализации агрегата:


  1. Свойства с модифицированными set'ерами, в которых сокрыта логика обнаружения изменений. Код получается неоправданно усложнённым, и не совсем понятно зачем. Мы имели такую реализацию, когда ещё оперировали анемичной моделью (вспоминаю как страшный сон).
  2. Aggregate Snapshots. Механизм делает регулярно или по триггеру снимки агрегата и, если что-то поменялось, регистрируется событие.
  3. Иммутабельные агрегаты, порождающие через бизнес-методы новую версию агрегата. В нашей команде прижился 3й вариант он сулит самые большие перспективы для распределённой системы.

Итак, строение агрегата.


  • Анемичная модель. Анемичных модели у нас две: обычная, и "дефолтная", с пустыми объект-значениями и корнем. При этом анемичная модель условная часть агрегата, существующая только для организации жизненного цикла данных, т.е. в репозитории, фабриках.
    • Идентификаторы. Мы используем составной ключ <guid, long>. Первая часть идентифицирует агрегат, вторая его версию.
    • Корень агрегата. Обязательная сущность, вокруг которой и строится ограниченный контекст. С этим элементом у нас были проблемы, мы ожидали что корень будет иммутабельным на всём протяжении жизненного цикла агрегата, однако, практика показала другое, нежели в книгах. Позже слышал на DDDevotion от Константина Густова то же самое.
    • Объект-значения. Простой иммутабельный класс: конструкторы закрыты, фабричные методы открыты.
  • Бизнес-методы. В нашей реализации составной объект, состоящий из предусловий и постусловий. Результат выполнения операции усложнённая монада Result или сложная структура, возвращающая две анемичных модели и результат операции. Результаты операций на данный момент делим на:
    • Успешные.
    • Ошибочные по бизнес-проверкам, которые могут порождать новую версию агрегата, однако, могут иметь место проблемы с постусловиями.
    • Фатальная проблема, когда предусловие говорит о том, что данная операция не может быть выполнена.

Доменные сервисы


Этот слой ответственен за работу с агрегатом. Состоит двух механизмов:


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

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


Слой приложения


Слой приложений довольно обыденный. Где-то свои обработчики, где-то на основе MediatR, но, в любом случае, всем командам ограниченного контекста надлежит получить из DI-контейнера провайдер агрегатов, а затем в обработчике из него (что?) определённую версию агрегата, у которой уже вызывается бизнес-метод.


Слой сервисов


С сервисами всё интересно. По умолчанию, мы продолжаем использовать .NET Core Web API, т.е. REST, протокол. Однако, REST это про архитектуры TableModule и нельзя использовать глаголы PUT, DELETE для модифицирования агрегата. Контроллеры наших микросервисов повторяют методы агрегата, используя глагол POST, ведь для стратегических паттернов нужны идемпотентные операции. В итоге получается дисфункция использования контроллеров. Возможно, следует использовать gRPC.


Инфраструктурный слой


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


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


Как это выглядит в итоге


С одной стороны:


Описание Зарисовка
Гексогональная архитектура микросервисов, декомпозированных по субдомену. image
Команда над доменной сущностью порождает новый объект (версию). image
Сравнение версий агрегата и метаданные команды (источник доменного события). image
Для распространений изменений используется ШДС, что открывает возможности для CQRS и ES. image
Версионирование команд и агрегатов должны помочь избежать блокировок и перепроверок при помощи оптимистичных блокирок. Появлется возможность ветвлений-сессий. image

С другой стороны:


  1. Тактические паттерны освоены костяком команды. Каждый может вести свою команду, распространять подход дальше.
  2. Наработки позволяют начинать работу с контестом даже если единый язык беден, оставив от модели лишь корень. По мере уточнения общеупотребимого языка, модель будет расширяться.
  3. Из всех взятых в работу ограниченных контекстов генерируются доменные события пригодные к использованию в смежных ограниченных контекстах.
  4. Предметная сложность полностью в модели. Даже инфраструктурных сложностей нет как таковых понятная работа по материализованным представлениям, обработчикам слоя приложения. Вместе с решением технической сложности, появляется soft-slills сложности.

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




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

Подробнее..

Иной подход к коммуникации удаленных команд

19.04.2021 20:16:49 | Автор: admin

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

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

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

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

Toolkit больше не нужен

Toolkit означает - в каждой команде свой хаос. Объясню почему. Когда формируется новая команда, каждый её юнит привносит свои знания. Со временем появляется набор инструментов и практик.

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

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

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

Живой пример

Frontend-разработчик Павел пришёл в новый коллектив. В прошлой команде дизайнер рисовал интерфейсы в Sketch (но у паши Винда и он использовал Lunacy), правки доносил через Google Docs, а бизнес логику показывал через Zoom.

А в новой команде используют Figma и Miro. Часть бизнес-логики показывают, через кликабельный прототип. Правки присылают в Телеграм, Slack, либо ставят в задачи в JIRA (но переписка как правило ведётся в мессенджерах).

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

Что, если Паша в прошлой команде работал в нашем инструменте, а в новой используют его же? Как Паша и команда выигрывают?

Обзор возможностей

Конкретика

Наш сервис решает ваши задачи конкретным способом, поэтому 1 раз изучив, можно использовать эти знания в любой команде. Тем более, что сервис будет интуитивно понятен всем, кто работал с PowerPoint, Miro и Figma.

Интерфейс модуля CaseTrackerИнтерфейс модуля CaseTracker

Накапливаемый опыт

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

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

Всё в одном месте

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

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

Бизнес-логику теперь проще донести

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

Как водится, это видео полетит в мессенджер и там же будет по нему переписка. Либо в JIRA, в виде задачи, но опять же, часть вопросов будет в комментариях к задаче, а часть в переписке в мессенджерах или ещё хуже - при созвоне (половина забудется). И потом концов не соберёшь.

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

Обсуждения с командой

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

Итог

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

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

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

Для первой тысячи мы откроем premium-доступ на целый год бесплатно - после запуска MVP.

Для связи со мной Телеграм. Подробнее о сервисе в моём инстаграм.

Подробнее..

Start Up Опыт и предпосылки заморозки в крупной IT-компании

18.03.2021 18:13:59 | Автор: admin

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

Итоги стартапа

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

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

  • Продуктовые команды успешно выпустили 20 версий на продуктивную среду клиенту;

  • Продуктовые команды успешно выпустили 240 новых фич клиенту;

  • Продуктовые команды эффективно использовали SCRUM в контексте ценностей, ролей, артефактов и ритуалов;

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

  • Текучка кадров составила 5%, и то это были два разработчика, которых перехантили обратно компании из которых они пришли;

  • Обработали 600 обращений непосредственно от пользователей продуктов;

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

В разрезе добавочной стоимости запуск стартапа обеспечил следующее:

  • вывод конкурентного решения на рынок умной поддержки;

  • инновационность продуктового решения;

  • создание производственной бизнес единицы;

  • создание и развитие трех продуктовых команд с 0;

  • увеличение капитализации материнской компании на стоимость созданного производства;

Предпосылки заморозки стартапа

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

Клиентская база

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

  • расширение своей клиентской базы в разрезе рынков b2b, b2c;

  • распределение функции управления клиентом в продуктовые команды;

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

Маркетинговые каналы

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

  • участие в профильных семинар и конференциях;

  • ведение продуктовых страничек на популярных IT ресурсах;

  • создание и развитие бренда;

  • создание вебсайта продуктов;

  • SMM оптимизация;

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

Отсутствие фокуса на продуктовой цели

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

  • создание культуры продуктовых целей;

  • обучение и тренинг клиента;

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

Контрактная модель

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

  • переход на модель выпуска лицензий;

  • переход на модель подписки (PaaS);

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

Добавочная ценность продуктовой команды

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

  • присутствуют все необходимые компетенции для выпуска инкремента продукта;

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

  • наличие микроклимата бизнес внутри бизнеса;

  • ясная и понятная зона ответственности в разрезе продуктового портфолио;

  • простота в планировании выпуска инкремента продукта;

  • непрерывное развитие коллективного разума, который находит отображение в продукте;

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

  1. 70% на формирование команды, 30% на создание продукта при условии, что члены команды не знают, как работать по SCRUM и до этого не работали друг с другом; При данной гипотезе, материнская компания несет повышенные затраты на запуск стартапа, так необходимо запускать с 0 все необходимые механизмы. Данная гипотеза наиболее распространена для компаний с матричной структурой функциональных подразделений.

  2. 40% на формирование команды, 60% на создание продукта при условии, что члены команды знают, как работать по SCRUM, но до этого не работали друг с другом; Здесь достигается определенный паритет затрат между формирование команды и разработки непосредственно продуктов. Данная гипотеза может более апробирована в компаниях, где развита производственная культура гибкой разработки ПО;

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

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

Инспекция и адаптация

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

Подробнее..

Recovery mode SCRUM Понимание и применение фреймворка

21.04.2021 22:10:18 | Автор: admin

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

Для решения данной сложной задачи, была предложена программа, которая включает в себя 4 этапа:

  1. Оценка готовности производственных подразделений к трансформации

  2. Разработка этапов трансформации

  3. Разработка механизмов трансформации

  4. Разработка ценностной модели обоснования трансформации

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

  1. Понимание и применение фреймворка SCRUM

  2. Разработка и поставка продукта

  3. Гибкое управление продуктовыми направлениями

  4. Развитие продуктовых команд

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

Философия эмпиризма

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

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

Метод исследования

Метрика

Декомпозиция

Наблюдение за инструментами фиксации проблем (JIRA)

отсутствует декомпозиция - 0 баллов

1 уровень декомпозиции - 1 балл

2 уровня декомпозиции - 3 балла

3 уровня декомпозиции - 5 баллов

Проблема

Опрос респондентов: Как Вы относитесь к проблеме?

Проблема - негативное событие и его нельзя допускать - 0 баллов

Проблема - явление к которому я уже привык - 3 балла

Проблема - возможность для роста и изучения нового - 5 баллов

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

Негативная реакция со стороны руководителя - 0

Позитивная реакция со стороны руководителя - 5

Наблюдение за реакцией сотрудников при возникновении проблемы

Негативная реакция со стороны сотрудника - 0

Позитивная реакция со стороны руководителя - 5

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


Культурные ценности

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

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

Метод исследования

Метрика

Фокус

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

работа появляется спонтанно вне определенного контекста - 0 баллов

вся работа запланирована и выполняется в контексте спринта - 5 баллов

Открытость

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

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

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

Уважение

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

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

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

Смелость

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

участники настороженно относятся к сложным задачам, которые вызывают отторжение - 0 баллов

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

Приверженность

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

сотрудники не ощущают зоны ответственности, нет понимания собственного вклада - 0 баллов

сотрудники ощущают персональную ответственность перед командой и продукта; есть также понимание собственного вклада - 5 баллов

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


Команда как функциональная единица

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

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

Метод исследования

Метрика

Команда

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

отсутствует понятие команды - 0 баллов

команда образована по функциональному признаку - 1 балл

самоорганизация команды по предметному признаку - 3 балла

команда образована по предметному признаку (направление) - 5 баллов

Скрам мастер

Наблюдение за наличием функций:

- Развитие продуктовой команды
- Поддержка среды с культурными ценностям
- Поддержка среды в рамках фреймворка SCRUM
- Мотивация продуктовой команды
- Применение модели "Менеджер - слуга"
- Организация производства
- Решение внутренних и внешних конфликтов

роль отсутствует, функции роли отсутствуют - 0 баллов

роль отсутствует, функции роли присутствуют - 1 балл

роль присутствует, функции роли отсутствуют - 3 балла

роль присутствует, функции роли присутствуют - 5 баллов

Владелец продукта

Наблюдение за наличием функций:

- Разработка дорожной карты продукта
- Управление продуктовым бэклогом
- Планирование и развитие продукта
- Проведение демонстрации продукта
- Проведение ежедневных стендапов
- Разработка бизнес гипотез

роль отсутствует, функции роли отсутствуют - 0 баллов

роль отсутствует, функции роли присутствуют - 1 балл

роль присутствует, функции роли отсутствуют - 3 балла

роль присутствует, функции роли присутствуют - 5 баллов

Разработчик

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

роль включает в себя только компетенции программирования - 0 баллов

роль включает в себя все необходимые компетенции для поставки версии продукта - 5 баллов

[ 0 - 13] - низкий результат, характеризующий отсутствие команды в качестве производственной единицы признанной на уровне организации. Необходимо разработать комплексную программу мероприятий для выделения и формирования команды в контексте организационных уровней компании. Не допускается проводить мероприятия для отдельно взятых характеристик за рамками комплексной программы.

[14 - 20] - средний результат, характеризующий наличие команды как класса, но существуют определенные ограничения для полного раскрытия потенциала. Необходимо определить проблемные характеристики для улучшения и разработать мероприятия. Допускается применение мероприятий без общей программы.

[17 - 20] - высокий результат, характеризующий наличие самодостаточной организационной единицы производства инкремента продукта, признанной на уровне организации. При данном результате, рекомендуется сделать акцент на мероприятиях направленные на управление продуктом, непрерывное обеспечение качества и CI/CD, как вектор роста команды


События

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

  • кто должен коммуницировать?

  • когда должен коммуницировать?

  • с какой целью должен коммуницировать?

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

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

Метод исследования

Метрика

Спринт

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

событие отсутствует - 0 баллов

присутствует событие с фиксированной периодичностью (2-4 недели) - 5 баллов

Ежедневный стендап

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

событие отсутствует - 0 баллов

событие проходит каждый день и несколько раз - 1 балл

событие фиксировано по времени, проходит каждый день и больше 15 минут - 3 балла

событие фиксировано по времени, проходит каждый день и ограничено 15 минутам - 5 баллов

Планирование спринта

Наблюдение за событием на котором происходит планирование содержания инкремента продукта

событие отсутствует - 0 баллов

событие не имеет ритмичности и происходит хаотично - 1 балл

событие имеет ритмичность, но не ограничено по времени - 3 балла

событие имеет ритмичность и ограничено по времени (4 часа - 2х недельный спринт) - 5 баллов

Ревью спринта

Наблюдение за событием на котором происходит демонстрация работоспособного инкремента стейкхолдерам

событие отсутствует - 0 баллов

событие не имеет ритмичности и происходит хаотично - 1 балл

событие имеет ритмичность, но не ограничено по времени - 3 балла

событие имеет ритмичность и ограничено по времени (2 часа - 2х недельный спринт) - 5 баллов

Ретроспектива

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

событие отсутствует - 0 баллов

событие не имеет ритмичности и происходит хаотично - 1 балл

событие имеет ритмичность, но не ограничено по времени - 3 балла

событие имеет ритмичность и ограничено по времени (2 часа - 2х недельный спринт) - 5 баллов

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

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

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


Артефакты

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

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

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

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

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

Метод исследования

Метрика

Бэклог продукта

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

бэклог продукта отсутствует - 0 баллов

бэклог продукта имеет вид разбросанных задач - 1 балл

бэклог имеет вид отфильтрованного списка по предмету - 3 балла

бэклог единое место хранения всех задач по продукту - 5 баллов

Бэклог спринта

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

бэклог спринта отсутствует - 0 баллов

бэклог спринта имеет вид разбросанных задач - 1 балл

бэклог имеет вид отфильтрованного списка по предмету - 3 балла

бэклог единое место хранения всех задач по спринту - 5 баллов

Инкремент

Наблюдение за фактом выпуска протестированной и работоспособной версии продукта

понятие инкремента отсутствует - 0 баллов

понятие инкремента присутствует, но выпуск работоспособной версии не происходит по факту окончания спринта - 1 балла

понятие инкремента отсутствует, но выпуск работоспособной версии происходит по факту окончания спринта - 3 балла

понятие инкремента присутствует, триггером появления служит спринт - 5 баллов

[ 0 - 9 ] - низкий результат, характеризующий сложность существующих подходов в части управления и планирования содержанием работ. Данная сложность может быть причиной увеличения времени ожидания ответа на запрос внутри команды, а также причиной низкой концентрацией на актуальных задачах.

[10 - 12] - средний результат, характеризующий наличие артефактов, однако существуют ограничения для их эффективного использования. Ограничения могут быть обусловлены разбросанностью элементов бэклога , а также наличие дополнительных артефактов. Рекомендуется разработать мероприятия, направленные на выделение артефактов как отдельной практики, задуманной по определению.

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


Критерии завершенности

Список критериев завершенности (далее DoD, от английского definition of done) является формальным чек-листом для принятия решения о выпуске инкремента. Критерии определяются стандартами организации или в случае если они отсутствуют, то команда сама должна определить список DoD. По мере развития команды, список критериев завершенности будет развиваться параллельно улучшению качества выпускаемого инкремента.

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

Метод исследования

Метрика

Наличие списка DoD

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

DoD отсутствует - 0 баллов

DoD отсутствует, существуют разбросанные критерии - 1 балл

DoD присутствует, инкремент выпускается соответствия критериям - 3 балла

DoD присутствует, инкремент выпускается при соответствии критериям - 5 баллов

Проверка уязвимостей

Наблюдение за наличием критерия , который характеризует отсутствие уязвимостей в исходном коде

критерий отсутствует - 0 баллов

критерий есть, не участвует в принятии решения - 1 балл

критерий есть, участвует в принятии решения, не используется специализированное ПО (sonarqube) - 3 баллов

критерий есть, участвует в принятии решения, используется специализированное ПО (sonarqube) - 5 баллов

Покрытие исходного кода

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

критерий отсутствует - 0 баллов

критерий есть, не участвует в принятии решения - 1 балл

критерий есть, участвует в принятии решения, не используется специализированное ПО (sonarqube) - 3 баллов

критерий есть, участвует в принятии решения, используется специализированное ПО (sonarqube) - 5 баллов

Инженерные стандарты

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

критерий отсутствует - 0 баллов

критерий есть, не участвует в принятии решения - 1 балл

критерий есть, участвует в принятии решения, нет общей wiki страницы с описанием стандартов - 3 баллов

критерий есть, участвует в принятии решения, есть wiki страница с описанием стандартов - 5 баллов

Критерии приемки

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

критерий отсутствует - 0 баллов

критерий есть, не участвует в принятии решения - 1 балл

критерий есть, участвует в принятии решения, нет общей wiki страницы с описанием критериев - 3 баллов

критерий есть, участвует в принятии решения, есть wiki страница с описанием критериев - 5 баллов

Автотесты

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

критерий отсутствует - 0 баллов

30 - 50 % покрытие - 1 балл

50 - 80 % покрытие - 3 балла

80 - 100% покрытие - 5 баллов

Проверка безопасности

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

критерий отсутствует - 0 баллов

критерий есть, не участвует в принятии решения - 1 балл

критерий есть, участвует в принятии решения, не используется специализированное ПО - 3 баллов

критерий есть, участвует в принятии решения, используется специализированное ПО - 5 баллов

UI/UX стандарты

Наблюдение за наличием критерия, который характеризует соответствие стандартам дизайна и эргономики

критерий отсутствует - 0 баллов

критерий есть, не участвует в принятии решения - 1 балл

критерий есть, участвует в принятии решения, нет общей wiki страницы с описанием стандартов - 3 баллов

критерий есть, участвует в принятии решения, есть wiki страница с описанием стандартов - 5 баллов

Архитектурные принципы

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

критерий отсутствует - 0 баллов

критерий есть, не участвует в принятии решения - 1 балл

критерий есть, участвует в принятии решения, нет общей wiki страницы с описанием принципов - 3 баллов

критерий есть, участвует в принятии решения, есть wiki страница с описанием принципов - 5 баллов

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

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

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


Масштабирование

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

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

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

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

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

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

Метод исследования

Метрика

Кадровое обеспечение

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

запрос функциональных подразделений - 1 балл

запрос продуктовых команд - 5 баллов

Новый продукт

Наблюдение за способом мобилизации ресурсов на новые продуктовые направления

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

привлечение устоявшихся команд - 5 баллов

Новые клиенты

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

своя ветка для каждого клиента - 1 балл

общее ядро и собственная ветка разработки для каждого клиента - 3 баллов

единственная ветка разработки с общими архитектурными механизмами - 5 баллов

Архитектура

Наблюдение за способом развития архитектуры

монолитная архитектура - 0 баллов

микросервисный монолит - 1 балл

микросервисная архитектура - 3 балла

оркестратор - бизнес процессов - 5 баллов

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


Подробнее..

SCRUM Развитие сотрудников и продуктовых команд

27.05.2021 12:14:32 | Автор: admin

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

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

Остальные части программы оценки готовности к трансформации:
SCRUM: Понимание и применение фреймворка
SCRUM: Разработка и поставка продукта
SCRUM: Гибкое управление продуктовыми направлениями

Фасилитация встреч и мероприятий

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

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

Метод исследования

Метрика

Роль фасилитатора

Наблюдение за выделением роли фасилитатора в компании

отсутствует выделение и признание роли на уровне компании - 0 баллов

роль фасилитатора проявляется у сотрудников с не руководящими функциями - 1 балл

сотрудники с руководящими функциями выполняют роль фасилитатора - 3 балла

присутствует выделение и признание роли на уровне компании - 5 баллов

Знания фасилитатора

Наблюдение за проявлением знаний фасилитатора в рамках:

- Цель события
- Составные части темы для трансляции
- Бэкграунд и степень синхронизации участников
- Поведение участников в группах
- Набор используемых техник фасилитации

слабо развития система знаний фасилитатора - 0 баллов

сильно развития система знаний фасилитатора - 5 баллов

Навыки фасилитатора

Наблюдение за проявлением навыков фасилитатора:

- Ясное выражение мыслей
- Умение слушать, понимать быстро и фокусировать внимание на важном;
- Структурирование и ведение темы;
- Парафраз вклада участников
- Суммирование и визуализация основных моментов дискуссии
- Мотивация и подогрев участников
- Предоставление правил и инструкций события для участников
- Интеграция результатов смежных групп в общий процесс
- Управление таймингом
- Идентификация динамики группы и соответственная реакция
- Фиксация общего обзора события

слабо развития система навыков фасилитатора - 0 баллов

сильно развития система навыков фасилитатора - 5 баллов

Правила организации

Наблюдение за проявлением правил организации и проведения событий:

- Цель события и ожидаемый результат;
- Содержание и программа события;
- Участники и их роли;
- Время проведения, длительность и место;

Правила фасилитации не устанавливаются - 0 баллов

Правила фасилитации устанавливаются для событий - 3 балла

Для периодических событий , правила зафиксированы в едином месте (например confluence) - 5 баллов

Техники фасилитации

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

- Брейншторминг
- Консенсус
- Дискуссия
- Интервенция
- Фокус на повестку события
- Основные правила события

техники фасилитации не выделяются и не используются - 0 баллов

ограниченное использование техник фасилитации - 3 балла

проявление гибкости в использовании техник фасилитации в зависимости от ситуации - 5 баллов

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

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


Методы развития продуктовых команд

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

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

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

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

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

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

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

Метод исследования

Метрика

Коучинг

Наблюдение за принципом целеполагания команд продуктовых направлений

отсутствует роль, которая помогает команде ставить и достигать цели - 0 баллов

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

выделяется роль коуча, которая помогает команде ставить и достигать цели - 3 балла

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

Менторcтво

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

отсутствует роль, которая помогает адаптироваться сотрудникам - 0 баллов

проявление принципа самоорганизации при адаптации - 1 балл

выделяется роль ментора, которая помогает сотруднику с адаптацией - 3 балла

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

Терапия

Наблюдение за существованием механизмов психологической разгрузки

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

у сотрудников есть неофициальные каналы, где они могут поделиться переживаниями - 1 балл

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

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

Тренинг

Наблюдение за подходами обмена знаниями и опытом внутри компании

внутри компании тренинги не проводятся - 0 баллов

тренинги имеют несистемный характер проведения - 1 балл

существует комьюнити экспертов для проведения тренингов - 3 баллов

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

Консультация

Наблюдение за подходами обмена знаниями и опытом снаружи компании

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

компания принимает активное участие в семинарах и воркшопах - 3 балла

компания принимает активное участие в семинарах, существуют партнерские отношения с проверенными консультантами - 5 баллов

[ 0 - 10] - низкий результат, характеризующий отсутствие у компании осмысленного подхода к развитию и адаптации кадров. В случае динамической среды стартапа, может наблюдаться эмоциональное выгорание сотрудников на горизонте испытательного срока; в случае умеренной корпоративной среды, наблюдается проявление низкой культуры развития сотрудников, как осознанный выбор компании для снижения затрат рынка низкотехнологичной продукции. При данном результате, целесообразность разработки программы обусловлена видением инвесторов в части долгосрочности нахождения компании на рынке, а также высокотехнологичностью продукции.

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

[21 - 25] - высокий результат, характеризующий зрелую систему развития и поддержки продуктовых команд. В арсенале компании имеются все доступные методы для формирования у сотрудников необходимого проактивного паттерна отношения к труду, новых навыков и знаний. При данном результате, компания осознаёт необходимость инвестицией в человеческий ресурс, так как он является потенциалом роста продуктовых направлений. Рекомендуется рассмотреть создание образовательного комплекса (аналоги GeekBrains, SkillFactory и т.д.) в периметре компании в целях становления и развития кадрового резерва.


Стили управления

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

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

Метод исследования

Стиль коуча

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

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

Стиль идеолога

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

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

Стиль слуги

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

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

Стиль автократа

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

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

Стиль невмешательства

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

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

Стиль демократа

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

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

Стиль темпа

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

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

Стиль трансформатора

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

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

Cтиль операционный

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

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

Cтиль бюрократа

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

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

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

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

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

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

Подробнее..

Из песочницы Start Up Организационные и технические аспекты запуска в крупной IT-компании

26.10.2020 00:19:14 | Автор: admin

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


image


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


Продукты стартапа


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


  1. Поиск жизнеспособной экономической модели продукта;
  2. Развитие и масштабирование продукта.

Два наших продукта ЧАТ СТП и ЕЦУ прошли первый этап и в настоящий момент имеют дорожную карту развития вплоть до 2022 года. Поставка MVP третьего продукта Сервисы ИИ для подтверждения жизнеспособности концепции ожидается к концу 2020-го, после чего будет принято решение о выделении инвестиций для развития и масштабирования.


image


Теперь по порядку немного о наших продуктах молодого департамента ЦИИ Центр искусственного интеллекта в ОТР2000. Продукт Чат СТП (неформальное название Мессенджер). Данный продукт предназначен для предоставления технической поддержки клиенту в части сопровождения информационных систем в B2B- и B2G-секторе. Мессенджер является дополнительной альтернативой телефонным обращениям и включает в себя кастомизируемый под свои потребности жизненный цикл обработки обращений.


Продукт ЕЦУ единый центр управления (неформальное название Супервизор). Идея ЕЦУ обеспечить омниканальность различных ИС заказчика в одной системе для эффективного управления и получения всей доступной информации в одном инструменте. ЕЦУ является мощным аналитическим инструментом в части сопровождения проектов и информационных систем.


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


Результаты продуктовых команд


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


  1. Короткие релизные циклы;
  2. Отношение выпущенных фич к новым в бэклоге;

image


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


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

Становление и развитие продуктовых команд


Культурная среда компании является началом проведения трансформации в части новых практик и подходов. В нашем случае компания ОТР2000 является системообразующей IT-компанией, надежно закрепившейся на B2G-рынке с 2000 г., и насчитывает около 4000 сотрудников, географически распределенных по всей России и за рубежом. На протяжении 20 лет компания экспоненциально росла в части поддержки и развития своих продуктов, что отразилось в выстраивании жесткой матричной структуры департаментов управления. Данный выстроенный механизм имеет водопадную структуру, и перед тем как выпустить очередную версию продукта, необходимо пройти фиксированные этапы через департаменты.


  1. Департамент бизнес-анализа.
  2. Департамент проектирования.
  3. Департамент разработки.
  4. Департамент тестирования.
  5. Департамент выпуска версий.

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


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


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


image


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


  • Владелец продукта отвечает за содержание бэклога и видение продукта
  • UX/UI отвечает за дизайн продукта и пользовательский опыт
  • Архитектор отвечает за архитектуру продукта и интеграционные вопросы
  • Backend-инженер отвечает за back продукта
  • Frontend-инженер отвечает за front продукта
  • QA-инженер отвечает за работоспособность продукта
  • DevOps отвечает за выпуск продукта
  • Скрам мастер отвечает за коммуникации и развитие продуктовой команды

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


  1. Первый этап Обнуление. На данном этапе все члены команды должны были забыть старые подходы из того времени, когда они работали в больших департаментах, так как от них теперь не требовались бумаги для перехода из одного этапа на другой. Теперь в команде были все необходимые роли для решения открытых вопросов и развития собственных процессов и подходов.
  2. Второй этап Коммуникации. В одной команде сфокусированы все необходимые роли, скрам-мастер внедрил необходимые ритуалы для поддержки процесса разработки выпуска работоспособных версий продуктов, что упростило коммуникации для решения многих проблем.
  3. Третий этап Роль владельца продукта. Данный этап является самым важным, без него команда не сможет сформироваться и дальше начать развиваться. Понимание и принятие роли владельца продукта должна пройти не только на уровне команды, но также на уровне заказчика и компании в целом.
  4. Четвертый этап Роль скрам-мастера. Скрам-мастер не является руководителем сверху, наоборот, принимая все преимущества модели manager as servant, создает и развивает организационные механизмы разработки продуктов таким образом, чтобы команды ни в чем не нуждались и находились в непрерывном росте и развитии.

Ритуалы в продуктовых командах


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


image


Мы успешно апробировали и используем следующие ритуалы в рамках 2-недельного релизного цикла:


  1. Stand Up ежедневная 15-минутная встреча, на которой каждый участник команды рассказывает об успехе проделанной работы, блокерах и планах на текущий день. В качестве инструмента используется Kanban-доска.
  2. Release Planning двухнедельная 2-часовая встреча, на которой проходит планирование очередной версии продукта, где команда декомпозирует пользовательские истории (user stories) на подзадачи и оценивает сроки реализации в попугаях. В качестве инструмента используется бэклог продукта.
  3. Demo двухнедельная 2-часовая встреча которая проводится после выпуска версии продукта с целью демонстрации нового функционала и получения обратной связи от клиента. В качестве инструмента используется протестированная и работоспособная версия продукта.
  4. Retrospective 2-часовая встреча, которая проводится после выпуска 34 версий с целью анализа организационных подходов и поиска их улучшений. Результатами данной встречи являются конкретные шаги, направленные на улучшение качества и скорости выпускаемой версии.

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


Организация CI/CD релизов


В целях организации короткого инкрементного релизного цикла мы внедрили CI/CD-подход. Данный подход заключаются в следующих технических и организационных возможностях:


  1. CI (continuous integration) непрерывная поставка инкремента продукта в виде MR (merge requests) в общий репозиторий программного кода командой продукта.
  2. CD (continuous deployment) непрерывная компиляция и сборка продукта из общего репозитория программного кода продукта.

image


Имея данные возможности, продуктовая команда быстрее определяет проблемы и дефекты при очередном CD, а также устанавливает причинно-следственные связи для их устранения. Для продуктов команд ЦИИ мы в среднем имеем 15 МР и 4 деплоя сборки в день. На картинке проиллюстрирован общий организационной подход в рамках внедрения CI/CD в разрезе управления средой разработки для одной из команд. Отображение данного подходя является базовым, что обеспечивает легкость масштабирования на дополнительные команды и смежные продукты.


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

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

Единственным критерием внедрения эффективного CI/CD-подхода является полное прохождение жизненного цикла сборки от локального MR отдельного разработчика до установки версии в продуктивную среду силами одной команды. Ответственным за процесс и работы CI/CD составе команды отвечает DevOps-инженер.


Инструменты продуктовых команд


Существует много моментов, которые мы хотели бы показать в рамках использования и внедрения инструментов разработки продуктов. Однако в этой статье мы лишь подсветим основные инструменты, которые прижились и доказали эффективность:
Управление содержанием продукты Atlassian (JIRA, Service Desk, Confluence).
Управление CI/CD Gitlab.
Управление коммуникациями Discord, Telegram.
Управление развитием команд Mural.


Интересные лайфхаки при использовании инструментов:


  1. Управление каждым продуктом осуществляется с помощью двух проектов JIRA:
    a. JIRA управления бизнес-требованиями, к которой имеет доступ клиент, генерируя поток новых идей. С использованием данной JIRA заказчик понимает, что TTM (time to market) равно 1 месяц.
    b. Производственная JIRA разработки функционала, к которой клиент не имеет доступа, и он понимает, что уровень декомпозиции новых фич позволяет выпускать версии каждые две недели для приемки в разрезе бизнес-требований.
  2. Для каждого из продуктов настроен свой репозиторий, который исключает зависимость продуктов друг от друга для релиза.
  3. Мы замкнули все внутренние и часть внешних коммуникационных каналов в одном инструменте. Таким образом обеспечивается легкость управления данными коммуникациями через каналы, и все команды находятся в одном информационном поле.
  4. С помощью webhooks можно с легкостью настроить нотификацию в дискорде в части бизнес-логики использования JIRA. Например, появилось новое требование для продукта в JIRA, нотификация автоматически появляется в нужном канале для привлечения внимания.
  5. Инструмент Mural является универсальным, и там много встроенных шаблонов для фасилитации встреч; он является палочкой-выручалочкой для каждого скрам-мастера.

Заключение


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


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

Ссылки на источники литературы
[1] Стив Бланк, Боб Дорф Стартап. Настольная книга основателя.
[2] https://agilemanifesto.org/iso/ru/manifesto.html

Подробнее..

Тимлид и здоровье его команды

23.11.2020 20:22:46 | Автор: admin

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

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

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

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

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

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

Этап развитиякоманды

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

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

Идеальная сферическая команда ввакуумеИдеальная сферическая команда ввакууме

Скорее вот такой:

Реальная команда в атмосфере компанииРеальная команда в атмосфере компании

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

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

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

Отпуски, переработки, дежурства

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

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

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

Предыстория побед и поражений

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

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

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

Текущие конфликты

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

А вот иррациональные конфликты или полный штиль повод присмотреться.

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

Цели и задачи стоящие перед командой и отдельными участниками

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

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

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

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

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

Договоренности и обязательства

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

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

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

Самостоятельность

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

Что измерять?

Еще одна интерпретация рычагавластиЕще одна интерпретация рычагавласти

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

Искренность и токсичность

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

Что важно?Отслеживать вектор демотивации и не делать преждевременных действий. Вытаскивать конструктивную критику из юмора и трезво смотреть на нее.

Неформальные взаимодействия

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

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

Обучение

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

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

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

Концентрация знаний

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

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

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

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

Для чего?Выждать если необходимо или возглавить изменения. Иногда это повод для того, что бы отложить выводы о состоянии команды до окончания изменений.

Производительность

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

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


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

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

Попробуйте применить разные линзы для взгляда на команду. Если вы любите больше формализации, процессов и индикаторов попробуйте методику Health Checkот Spotify.

Подробнее..

Самодиагностика команды разработки

20.05.2021 08:20:21 | Автор: admin

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

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

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

Опросы

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

Еженедельный опрос

В конце каждой недели мы получаем опросник на 30 секунд с вопросами: как часто у вас не было сил выполнять работу? Получал ли удовольствие от задачи? Сколько часов переработал? На выходе мы строим график для всей команды в динамике за последние 6 недель и обсуждаем на ретроспективе.

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

Опрос в конце спринта

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

Опросы раздражают

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

Мотивация

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

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

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

Боли (от выполнения ручной/неудобной работы)

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

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

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

  • Опять же посмотреть в Jira и рассмотреть что мы можем делать лишнего, или что уже не актуально и можно упразднить. Например, мы рассматривали релиз-тикеты и пытались понять какие моменты мы можем делать быстрее. Так мы обнаружили, что security scan кода занимал по 20-30 минут, мы подумали, что можно делать всё проще и в итоге сейчас это занимает около 5-10 минут.

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

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

  • Изучение будет происходить в паре/тройке. Так и интересней, и если кто-то уйдёт в отпуск - работа не встанет.

  • Пары/тройки будут меняться в будущем. Чтобы команда не дробилась на небольшие "кружки по интересам" и оставалась одной командой.

  • Внутри пары/тройки нет ограничений на источник обучения. Кому-то могут нравиться курсы с LinkedIn, кому-то с Udemy, а кто-то вообще нашёл крутой разбор темы на YouTube на своём родном языке.

Больше болтовни

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

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

Также мы заметили, что когда люди включают web-камеру - они более искренне и более разговорчивы. Если вся команда не разговорчива, мы просто используем Wheel Of Names и там уже рандомом выбираем кто будет говорить.

Фидбеки

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

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

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

  • Кастомеры задавали вопросы на одни и те же сообщения в логе. Суть в том, что в логе мы печатали что-то вроде "Module: service XXX call, RC = Y, RSN = ZZ". Т.к. это вообще не понятно никому, L2 выстраивали у себя сводную таблицу таких сообщений, чтобы отвечать кастомерам. Если какая-то новая комбинация - то это шло дальше в L3 (к разработчикам). Решением было простым: мы просто написали функцию которая по кодам печатает user-friendly сообщения с полным описанием причины проблемы.

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

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

Ежедневный отчёт

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

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

Свои метрики

Внутри команды у нас есть свои метрики. Некоторые пересекаются с менеджерскими, некоторые уникальны.

Например, кастомерские проблемы идут в приоритет и нам, как команде, очень важно, чтобы оно в L3 находилось как можно меньше времени. Поэтому мы стараемся отвечать на проблему, либо находить реальную причину (например, баг) как можно быстрее. Менеджмент всего лишь следит, чтобы ответ был не дольше чем за 2/7 дней (в зависимости от важности проблемы - у них свои метрики).

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

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

Больше правил

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

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

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

Также, правила должны подвергаться пересмотру. Например, в какой-то момент времени у нас случилось несколько кастомерских проблем из-за релиза, баги в котором могли быть замечены аж на трёх этапах: Разработка (code review), Просмотр билда разработчиками, и уже QA. На всех трёх этапах можно было предотвратить ошибку. Разумеется, после этого инцидента все этапы были ужесточены. В итоге то, что раньше могло занимать до 5 дней, стало занимать до 10 дней. Со временем все ужесточения были пересмотрены. Некоторые до сих пор остались, просто был изменён процесс чтобы действие занимало меньше времени, что-то было упразднено, а что-то наоборот добавилось.

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

Ответственность на всех

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

  • Плохие вещи случаются. Нельзя запланировать и предвидеть всё.

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

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

  • Обвинения не решают проблем. Вообще никаких.

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

  • Женщину, которая в полной темноте переходила дорогу в неположенном месте?

  • Водителя автомобиля с автопилотом, который вряд ли сам среагировал бы?

  • Компанию, которая разрабатывает автопилот?

  • Разработчиков, кто писал код для автопилота?

  • QA кто выпустил этот код в прод?

Субъективно, тут виноваты все, либо никто. Но, очевидно, что виновные есть, т.к. в итоге женщина скончалась. Значит виноваты все.

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

Team Building

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

Заключение

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

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

Подробнее..

Какой должна быть команда стартапа

02.11.2020 14:14:45 | Автор: admin
Какой должна быть команда стартапа

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



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

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

Hipster, Hacker, Hustler
Теория, впервые высказанная техническим директором AKQA Рей Инамото Hipster-Hacker-Hustler или 3H, описывает, какие именно люди нужны для успеха компании. Рей выделяет 3 типа ролей, которые, будучи в вашей команде, вместе и создают своеобразную формулу успеха. Именно эти 3 роли должны быть в минимально жизнеспособной команде, чтобы заинтересовать инвестора, двигаться вперед к успеху и активно расти.

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

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

The Hustler
Возможно, все, что до своего стартаперского настоящего вы знали о Хастлере, это то, что есть такой журнал. Отлично! Тогда вы знаете, что для хастлера нет почти ничего запрещенного. На пути к продажам, конечно, а вы о чем подумали?

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

В качестве примера Хастлера западные эксперты называют Шерил Сэндберг.
Операционный директор (COO) Facebook, Шерил Сандберг является одновременно бизнес-магнатом и вдохновляющей фигурой для молодых женщин. Начав свой путь в качестве выпускника факультета экономики (Гарвард), Шерил быстро поднялась по карьерной лестнице и получила места в престижных учреждениях, таких как Министерство финансов США и Google. В конце 2007 года Шерил познакомилась с соучредителем Facebook Марком Цукербергом на рождественской вечеринке, и вскоре ей предложили должность операционного директора компании. Как вам такие навыки коммуникаций?

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

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

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

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

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

Я тимлид, зачем мне все это?

29.01.2021 10:18:54 | Автор: admin

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

Ну правда, зачем? Задача тимлида сделать всё, чтобы команда работала эффективно. Зачем быть искренним и эмпатичным, если люди это ресурс, и вы умеете ими управлять?

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

С этого и начну.

Самосознание

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

Понимание мотивации и интересов сотрудников

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

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

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

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

Но постепенно всё начало разваливаться: команда вносила что-то своё, свои идеи, критиковала продукт, говорила, что здесь что-то не так, здесь что-то не то И тимлид попадал в ситуацию непонимания: в каком смысле что-то не то? Мы делаем с вами вот такой продукт, это же так здорово! Почему вы к этому не относитесь так же, как я? Он не мог даже подумать, что другой человек, разработчик из его же команды, может отличаться по своей мотивации от него самого. Он был уверен, что все в команде смотрят на мир такими же глазами, как он.

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

Разрешение конфликтов

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

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

  • качественно проживать свои эмоции

  • понимать, что в каждом случае вы хотите получить

  • как вам важно эту ситуацию разрулить

  • чему вы сможете своих сотрудников в связи с этим обучить

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

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



Подробнее..

Перевод Никаких митингов, дедлайнов и сотрудников на полную ставку

06.05.2021 12:20:25 | Автор: admin

Я основал компанию Gumroad в 2011 году. В 2015 году у нас было рекордное количество людей - 23 штатных сотрудника с полной занятостью. В 2016 году, после неудачной попытки поиска финансирования, я вернулся в точку, с которой начинал. В компании снова был всего один сотрудник - я сам.

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

Если посчитать всех, кто работает в Gumroad, получится 25 человек.

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

У нас нет совещаний и нет дедлайнов.

И этот подход работает: наши авторы зарабатывают более 175 миллионов долларов в год, а компания в среднем зарабатывает 11 миллионов долларов в год, и эта цифра растет каждый год в среднем на 85%.

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

Свобода любой ценой

После массовых сокращений в 2015 году компания Gumroad продолжила расти, несмотря на потери среди персонала.

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

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

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

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

У меня не было цели, чтобы Gumroad стал приносить миллиарды, но зато у меня появился новый актив - время. Я использовал это время, чтобы обучаться написанию текстов и рисованию.

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

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

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

Как мы работаем

На сегодняшний день работа в Gumroad похожа на работу в проекте Open Source, например, таком как Rails. За исключением того, что это не Open Source, и эта работа оплачивается.

Вместо того, чтобы сидеть на совещаниях, люди "общаются" друг с другом, используя такие сервисы, как GitHub, Notion, и (иногда) Slack, и отвечают друг другу в течение 24 часов. Так как у нас нет стендап-митингов или "скрамов", а некоторые проекты требуют достаточно долгого и тщательного обсуждения, которое зачастую обходится компаниям дорого, наш принцип работы требует способности изъясняться ясно и умения доносить свои идеи.

Все пишут хорошо, и пишут много.

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

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

Но мы не ставим жестких рамок и приоритетов.

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

Точно таким же образом мы работаем над масштабными задачами.

В ноябре 2020 года мы запустили проект Gumroad Memberships, который действует уже год и благодаря которому сотни авторов, использующих новую систему, зарабатывают более 1 500 000 долларов в месяц.

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

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

По словам разработчика Gumroad Хелен Худ, которая работала над созданием Memberships: "Это был один из самых масштабных запусков продукта за всю мою карьеру, и мы сделали этот проект без единого митинга или видеозвонка. У меня есть опыт работы в обычном стартапе с известной всем корпоративной культурой - открытый офис без дверей, множество белых досок, стендап-митинги и планирование спринта, пиво с коллегами после работы. Также у меня был проект, где все работали удаленно, было мало коммуникации, и программисты в основном работали каждый над своей задачей, они не были одной командой. Для меня то, как мы работаем в Gumroad - это идеально. Это позволяет мне с максимальной пользой использовать часы, когда я продуктивна, и заканчивать работу, когда я достигла своего предела".

Это весьма краткое описание, но мы опубликовали еще несколько статей, в которых подробно описано, как мы работаем:

  • Как мы решаем, над чем работать? "И конечно, нельзя не отметить, что в Gumroad вкладывается очень много эмоций, этим он ничем не отличается от других арт-проектов. Иногда мы выбираем то, что интересно и над чем нам нравится работать! Мы любим прислушиваться к авторам! Мы никогда не проводим масштабный анализ данных, чтобы решить, над чем стоит работать дальше".

  • Как мы общаемся? "Отключите все уведомления в телефоне!"

  • На что похожа работа в Gumroad?

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

  • Есть ли негативная сторона у работы в Gumroad? "В компании не так уж много возможностей для роста. Компания приносит доход, и мы не планируем увеличивать команду каждый год и набирать много людей. Хотя у нас скорее всего и будут руководящие должности, их немного, и они не являются ступенькой какой-либо внутренней карьерной лестницы, по которой мог бы двигаться сотрудник Gumroad".

Сотрудник Gumroad Крис Максимин сообщает: "Этот принцип работы позволил мне достичь наибольшей продуктивности, которая у меня когда-либо была. Возможность сконцентрироваться только на работе и на том, что действительно важно, создает благоприятный цикл взаимодействия, который приносит положительные результаты и компании, и сотрудникам: 1) компании не нужно платить огромные зарплаты программистам за то, что они часами сидят на бесконечных и бесполезных митингах, и 2) программисты могут сделать больше задач и научиться многим вещам, что принесет им огромную пользу в долговременной перспективе".

И так работают не только программисты.

Джастин Миколай, занимающийся написанием текстов в Gumroad, точно так же работает над каждой публикацией Creator Spotlights, хотя над каждой статьей трудятся минимум три человека, плюс создатель контента.

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

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

Такой способ работы не для всех.

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

Но мы можем конкурировать (и выигрывать!) за счет нашей гибкости.

Сид Ядав, ранее занимавший должность вице-президента по продукту в компании Teachable, стал частью команды Gumroad в 2018 году.

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

В 2020 году Сид ушел из компании и вместе со своим бывшим коллегой из Gumroad Руди Сантино основал свою собственную компанию Circle, которая также предоставляет площадку, где авторы могут продавать свои работы и услуги.

Я основал новую компанию: cycle.so! В течение следующих недель я подробнее расскажу о ней, но сегодня я хотел бы выразить благодарность тем жизненным обстоятельствам, благодаря которым это стало возможным - это моя работа на гибком удаленном проекте @gumroad. Без Gumroad мне бы не удалось достичь этого.Я основал новую компанию: cycle.so! В течение следующих недель я подробнее расскажу о ней, но сегодня я хотел бы выразить благодарность тем жизненным обстоятельствам, благодаря которым это стало возможным - это моя работа на гибком удаленном проекте @gumroad. Без Gumroad мне бы не удалось достичь этого.

Работа в Gumroad не является ни для кого главным приоритетом и основным способом самореализации.

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

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

Я тоже разделяю эту точку зрения.

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

Компания авторов контента

Однажды совершенно неожиданно я получил электронное письмо от Дэниела Вассалло. Я знал Дэниела; он является автором, который меньше чем за год заработал в Gumroad более 250 000 долларов.

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

Я люблю Gumroad (и я зарабатываю себе на жизнь с его помощью!), мне нравится заниматься разработкой стратегий и постановкой задач. Думаю, я мог бы заниматься проект-менеджментом в Gumroad. В среднем я мог бы уделять этой работе всего 2 часа в день, но я буду доступен каждый день. Не знаю, готовы ли вы пойти на такие условия, но я подумал, что если кто-то и может на такое согласиться, то это Gumroad :)

Он подходил нам идеально. Дэниел стал нашим новым менеджером по продукту.

Для Gumroad это тоже было выгодным предложением. До того, как Дэниел ушел из компании Amazon, он зарабатывал более 400 000 долларов в год. Мы же платим ему 120 000 долларов в год.

Как это возможно? У нас он работает 10 часов в неделю. По его словам:

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

Зарплаты

Фактически у нас почасовая оплата для всех сотрудников, и размер ставки зависит от занимаемой должности. Зарплаты варьируются от 50 долларов (специалист поддержки) до 250 долларов (менеджер по продукту) в час.

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

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

Зарплата обсуждается во время прохождения собеседования:

  1. Подача заявки через форму.

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

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

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

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

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

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

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

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

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

Именно такой должна быть работа в экономике творчества.

Будущее работы в том, чтобы не работать

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

Никто не согласился.

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

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

На главной странице Gumroad перечислены преимущества, которые есть у авторов, которые пользуются платформой: "Избавьтесь от офисной работы с 9 до 5. Снимите костюм и галстук. Больше никаких поездок на работу. Зарабатывайте на своем творчестве".

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

Познакомьтесь с командой Gumroad:

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

Подробнее..

Recovery mode Как поднять боевой дух команды на удаленке?

16.06.2021 10:13:29 | Автор: admin

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

Эта статья от том, как я организовал Хакатон для IT компании в Малайзии в самые первые месяцы пандемии. Игра была целиком посвещена Linux администрированию, траблшутингу и хакингу. При этом она позволяла поучаствовать всем сотрудникам, от junior инженера технической поддержки до senior архитектора.

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

Дано:

  • Компания системный интегратор в Куала Лумпуре;

  • Интернациональная команда IT-специалистов;

  • 99.99% персонала внезапно ушло на удаленку.

Задачи:

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

  • Развить навыки, используя геймификацию;

  • Развить внутренний бренд для будущих IT игр.

В чем заключалась сложность?

  • Неравномерный уровень подготовки и квалификации.

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

  • Сменный график работы сотрудников.

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

  • Локальный менталитет.

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

[Спойлер]

Мне удалось =)

А где Гарри? Шалит с новым хакатоном.А где Гарри? Шалит с новым хакатоном.
  • Неразбериха из-за пандемии.

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

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

  • Демотивированный персонал.

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

[Спойлер]

Еще как может! Риск не собрать аудиторию не оправдался.

Типичный сотрудник в самом начале пандемии.Типичный сотрудник в самом начале пандемии.

План подготовки и проведения хакатона

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

  • Разработка концепта игры.

Я решил, что темой хакатона будет Linux администрирование. Соответственно, задания должны были строиться вокруг базовых административных задач: проверялось умение использовать command line, браузерные тулзы, знание SQL, DNS, самые основы шифрования.

Хакатон должен был длиться несколько дней. Поэтому я придумал систему уровней и кодов. Каждый уровень представлял собой одну виртуальную машину, в которую участникам нужно было зайти по SHH и найти спрятанный код. На каждой из машин был запущен Apache c простым сайтом, где размещались подсказки. Ну или нет =)

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

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

На этом же этапе была продумана система поощрений.

  1. Top-3 самые ценные индивидуальные призы;

  2. Top-10 дополнительный специальный пак призов;

  3. Первые 50 участников гарантированные призы из дешевого ценового диапазона.

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

  • Технический дизайн.

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

В качестве хостинг площадки был выбран AWS. Игровые серверы и хост с веб формой были подняты на t2.medium EC2 инстансах. К каждому инстансу был привязан 1 бесплатный домен. В качестве базы данных использовалась Amazon DynamoDB. Форма была написана на Python и фреймворке Flask. Бэкенд формы был выполнен на основе FaaS (Function as a Service) подхода с помощью связки API Gateway + Lambda + DynamoDB.

Выбор такой технологической базы был обусловлен субъективными пожеланиеми организаторов, наличием необходимой корпоративной облачной подписки, и знаменитым правилом start where you are. Последний принцип подсказал, что можно взять подходящую web форму, используемую в продакшене, и переписать ее под нужды игры. Пользуясь случаем, Алекс и Саша, огромное спасибо за помощь с AWS деплойментом и девелопментом формы. Без вас мне бы было значительно сложнее.

  • Презентация концепта руководству и получение бюджета.

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

[Спойлер]
Как ощущаешь себя когда получаешь максимальный бюжет на проект.Как ощущаешь себя когда получаешь максимальный бюжет на проект.
  • Разработка дизайна и внешнего вида.

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

  • Выбор и заказ призов.

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

  • Рассылка тизеров до начала игры.

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

  • Сюжетное обрамление.

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

  • Релиз.

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

Один из финальных тизеровОдин из финальных тизеров
  • Элемент обучения.

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

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

  • Организовать постоянный follow up.

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

  • Выдать призы.

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

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

  • Собрать обратную связь.

Действовать следовало итеративно и с фидбеком. Поэтому всем участникам был разослан опросник. 25% заполнили его. Об ответах в описании результатов.

Весь подготовительный процесс занял 2 месяца и 68 человеко-часов главного организатора. Но результат стоил того.

Результаты:

  • Боевой дух команды вырос.

Игра подразумевала индивидуальное участие и решение задач. Однако, мне доподлинно известно, что люди объединялись в команды, устраивали созвоны и брейнштормы. Активным участникам точно было не скучно. Люди, которым в силу неопытности удалось прорваться только через несколько уровней, определенно научились чему-то новому. Цель отвлечь участников и снизить градус напряжения была достигнута.

  • Позитивный фидбек от участников.

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

Три наиболее частые причины почему участники согласились играть:

  1. Возможность проверить свои скиллы;

  2. Любовь к играм и соревнованиям;

  3. Любопытство.

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

  • Карт-бланш и бюджет на проведение новых хакатонов.

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

Личное:

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

А еще я сформулировал и взял на вооружение...

Ключевые принципы организации хакатонов.

  • Знайте свою целевую аудиторию.

Хакатоны - для всех!Хакатоны - для всех!

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

  • Агитируйте правильно.

[Спойлер]
Землю - крестьянам, игры - айтишникам!Землю - крестьянам, игры - айтишникам!

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

  • Управляйте сложностью.

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

[Спойлер]
У меня есть пароль, но нет логина. Зарепортить игровой баг или поискать еще?У меня есть пароль, но нет логина. Зарепортить игровой баг или поискать еще?
  • Позвольте играть не так как задумано.

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

[Спойлер]
А Барсик один в игре ковыряется, посмотри на него!А Барсик один в игре ковыряется, посмотри на него!
  • Призы хорошо, но не главное.

[Спойлер]
А как же сектор приз?А как же сектор приз?

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

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

Спасибо, что прочли. Увидимся в будущих публикациях!

Подробнее..

Быстрее нативной разработки опыт внедрения Flutter в крупной компании

18.12.2020 20:18:20 | Автор: admin

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

Задачи: почему мы вообще в это ввязались

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

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

  • покупателям для формирования корзины из фермерских продуктов и оформления заказов

Поиск решения: почему выбрали Flutter

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

По большому счёту, выбирали между нативом и Flutter. React Native и Xamarin отбросили почти сразу, с ними уже имелся опыт не очень удачный. Также рассматривали PWA, но этот вариант тоже пришлось забраковать: на момент выбора там было не всё хорошо с поддержкой нативных функций системы, особенно в iOS. К тому же для хорошей поддержки требовались свежие версии OS, что тоже могло стать проблемой. В общем, изучив вопрос поглубже, решили не собирать грабли.

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

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

  • виджетный (компонентный) подход, сродни React

  • кроссплатформенный меньше кода, потенциально упрощает тестирование

  • богатый инструментарий разработчика IDE и прочее

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

  • продукт, который развивает и продвигает Google и большое Open-source community

  • крупные компании Google, Groupon, Alibaba разрабатывают на нём свои приложения

Были и минусы:

  • мало разработчиков всего 121 резюме, 11 лидов/сеньоров в Москве

  • дорогие лиды/сеньоры

  • относительно мало технической информации stackoverflow и т.п.

  • пока мало готовых (сложных) компонентов стандартные/системные тут не используются

  • язык новичкам придётся учить Dart (но легко переходить, если есть опыт разработки на Java или JavaScript)

  • сложно найти подрядчиков с опытом

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

Пришлось фантазировать: формирование команды

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

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

Основная масса специалистов по Flutter это младшие разработчики, которые только начинают свой путь, а также старшие или ведущие, у которых есть время изучать современные технологии и пробовать их в виде proof of concept. Проще всего адаптироваться к Flutter тем, кто имеет опыт Android-разработки. На втором месте web-разработчики: react, vue.js здесь близкий по духу компонентный подход.

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

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

На сегодняшний день география команды довольно обширна: кроме москвичей, у нас работают жители Петрозаводска, Елабуги, Барнаула. Есть кандидаты технических и физико-математических наук. Таким образом, команда формировалась постепенно, параллельно с активной разработкой приложения. Сейчас у нас уже 7 разработчиков, появляются новые проекты на Flutter мы растём.

Изначально работу выстраивали по принципу feature-driven development (FDD, разработка, управляемая функциональностью). Но впоследствии решили перейти на унифицированный процесс разработки на основе OpenUP: такой способ лучше подходит для управления разработкой всего продукта и координации нескольких команд архитекторов, аналитиков, разработчиков, тестировщиков. Внутри команд разработки используем Scrum.

Особенности разработки на Flutter

Когда говорят о кроссплатформенной мобильной разработке, часто сравнивают React Native и Flutter. Однако нужно понимать, что React Native это не история про один код на все платформы. Недаром официальный слоган проекта Learn once, write anywhere. Дело в том, что в React Native пишут код на JavaScript, который использует нативные для каждой платформы компоненты и они довольно сильно отличаются. Да, есть общие компоненты, вроде Text и View: под обе платформы, хотя и с нюансами. Но много и таких, что работают только на одной ОС. Поэтому в React Native нередко можно встретить выражения:

if (Platform.OS == 'ios') ...`

При использовании Flutter разработка ведётся на языке Dart, который компилируется в нативный для платформы код. При этом вместо нативных компонентов используется собственная библиотека виджетов, которые выглядят как нативные Material и Cupertino для Android и iOS соответственно. Вы можете использовать виджеты из обеих библиотек в одном приложении, кроме того, их очень легко кастомизировать.

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

Бывает и так, что есть уникальная для платформы функциональность. Подстановка СМС-кодов верификации на iOS работает по умолчанию, от программиста не требуется никаких действий. А на Android нужно использовать системные методы, чтобы получить этот код программно и подставить в нужное поле. Хотя даже для этой задачи уже существуют Flutter-библиотеки, например, sms_user_consent. Весь платформенный код в ней уже создан, остаётся только добавить свой listener для получения сообщений.

if (Platform.isAndroid) {  listenForCode();}void listenForCode() {  smsUserConsent = SmsUserConsent(      phoneNumberListener: () {},      // Действия при получении смс-сообщения      smsListener: () {        Log('code is updated to ${smsUserConsent.receivedSms}');        final sms = smsUserConsent.receivedSms;        _smsCodeController.text = sms.substring(sms.lastIndexOf(' ') + 1);      });  smsUserConsent.requestSms();}

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

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

Разработка на Flutter значительно быстрее, нежели нативная. Если говорить о кодовой базе, то нативный мобильный код по объёму для каждой платформы по отдельности был бы примерно аналогичен Dart-коду, но за счет того, что платформ две, получаем существенное увеличение трудозатрат.

Результаты и выводы: стоит ли разрабатывать на Flutter

Новый фреймворк не подвёл: после полугода разработки MVP доступно в магазинах приложений для Android и iOS. Проект по-прежнему развивается, и в этом очень помогает фидбэк пользователей: мы активно взаимодействуем с фермерами, которые делятся своими впечатлениями от использования платформы. В ближайшем будущем хотим подключить к нашему маркетплейсу сторонние сервисы доставки, внедрить онлайн-платежи, организовать процесс совместных покупок. Для реализации этого нам понадобятся не только мидлы и сеньоры, специализирующиеся на Flutter, но и PHP-разработчики (Senior и Team Lead с опытом Magento 2), а также опытные специалисты по Vue.js. Если видите себя членом нашей новой команды обязательно пишите!

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

Единственный реальный риск корпоративные войны между Apple и Google. Если политика Apple в отношении приложений на Flutter изменится, это может негативно сказаться на его перспективах. Речь не только о процессе размещения в магазине приложений, но об инструментальных средствах, таких как совместимость SDK.

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

Подробнее..

Recovery mode Прокрастинация или просто лень? Как различить и победить и то, и другое

26.05.2021 14:12:47 | Автор: admin

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

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

Психологическая природа состояний

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

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

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

Только и делай, что ничего не делай...Только и делай, что ничего не делай...

В книге Прокрастинация: первая помощь ирландские психологи Таня ван Эссен и Хенри Шувенбур выделили пять этапов на пути от официального старта работы над задачей до ее завершения, чтобы понять, в какой момент человеку мешает прокрастинация, а в какой лень:

A. Момент появления задачи;

B. Оптимальный момент для начала работы;

C. Момент, когда вы решаете начать работать;

D. Момент, когда вы принимаетесь за работу;

E. Дедлайн.

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

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

Основными причинами состояния лени педагоги называют несформированность механизмов саморегуляции и дефицит мотивации.

Французский психолог Альфред Бине, исследовавший лень еще в конце XIX века, выявил два ее типа:

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

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

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

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

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

А некоторые откладывают на потом саму жизньА некоторые откладывают на потом саму жизнь

На пути от принятия задачи к дедлайну, который описали Таня ван Эссен и Хенри Шувенбур, проблемы с прокрастинацией обычно возникают в промежутке между этапами С и D. То есть, человек уже решил начать работать, а сами активные действия откладывает. Задача стоит в плане и постоянно напоминает о себе.

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

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

Читайте также 12 лайфхаков, которые помогут удержать клиентов в рекламном агентстве.

Распространенная причина прокрастинации временное снижение мотивации, часто из-за слишком сложной или скучной задачи.

Чем похожи и чем отличаются прокрастинация и лень

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

У этих двух состояний действительно есть кое-что общее:

  • причины возникновения обеих проблем отчасти лежат в области мотивации;

  • результат схож: дела не делаются или делаются с опозданием;

  • негативные последствия, пусть и разные, есть и у лени, и у прокрастинации.

На этом со сходствами, пожалуй, все. Переходим к различиям.

Основные особенности. Их мы уже упомянули в предыдущем разделе:

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

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

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

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

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

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

Или уже все?Или уже все?

Осознанность процесса и способность к прогнозированию. Тут механизмы лени и прокрастинации тоже работают немного по-разному.

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

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

Читайте также Топ-13 конструкторов чат-ботов для сайтов, мессенджеров и соцсетей.

Как победить лень и прокрастинацию

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

Как побороть лень

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

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

Зафиксируйте мотивацию письменно и держите перед глазамиЗафиксируйте мотивацию письменно и держите перед глазами

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

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

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

Теперь придется смотреть ;-)Теперь придется смотреть ;-)

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

Как взять прокрастинацию под контроль

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

  • 9:0011:00 аудит для нового клиента;

  • 11:0016:00 текущие проекты;

  • 16:0018:00 обучение.

Примерно так, но еще более детально: заносите в план обед, перерывы, бытовые дела. Так пространства для маневра останется меньше.

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

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

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

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

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

Чтобы облегчить себе жизнь, формулируйте задачи четко и конкретно:

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

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

А вы ленитесь или прокрастинируете?

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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru