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

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

Как устроена индустрия лицензирования кино? Почему Okko так лагает на PS4?

20.06.2020 14:17:11 | Автор: admin


9 июня в нашем инстаграм-аккаунте прошел прямой эфир с CTO Okko Алексеем Голубевым и вышла настоящая прожарка 99% вопросов составила критика сервиса.
Из-за этого получился скорее более продуктовый рассказ, чем технический, но по сложившейся традиции, мы выкладываем все расшифровки и записи эфиров.

***


Меня зовут Алексей, я технический директор компании Okko. Вопросов накопилось много, я постараюсь ответить на все.

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


Давайте расскажу, как в принципе работает индустрия лицензирование кино.

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

Раньше следующим этапом было открытие прав на продажу DVD/Blu-ray, и только после этого открывались права на цифровой показ. Несколько лет назад картина начала меняться под давлением сервисов, предоставляющих услуги цифрового показа Netflix, в первую очередь. Мы, конечно, тоже вносим свой вклад. Каждая большая студия проводит аудит онлайн-сервисов на предмет соответствия стандартам безопасности, и я стараюсь добавлять в переговоры тему сдвига релизного окна. Сейчас ситуация уже сильно изменилась: например, фильмы русских студий часто поступают в онлайн-кинотеатры еще до конца проката в физических кинотеатрах.

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

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

Когда у пользователя будет возможность вернуть деньги за неинтересный фильм? Например, с привязкой размера возвращаемых средств к процентам просмотра фильма.
Это интересная фича, и многие онлайн-кинотеатры о ней думают. Правда, надо понимать: за подобный прерванный просмотр фильма (обычно начиная с 20%) правообладатель все равно должен получить средства целиком, и в таком случае их должен будет заплатить кинотеатр. Может быть, такие затраты можно будет причислить к маркетингу. Общая цена фильма состоит из минимальной витринной цены (её тоже может устанавливать правообладатель), отчислений за подписку/продажу и отчислений вендорам платформ (например, Samsung SmartTV) то есть, за каждый просматриваемый фильм кинотеатр обязан заплатить как кинокомпании, так и вендору платформы.

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


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

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

Можно ли в Okko получить копию фильма без DRM, без дубляжа, с оригинальной дорожкой и качеством?


Исходник может занимать терабайт, например поэтому истинного исходного качества точно не может быть. Мы готовим контент для доставки по Интернету, режем на несколько разных битрейтов, кодируем 264/265 кодеком и выкладываем на разные платформы в разных типах стримов с поддержкой адаптивного битрейта. То есть, пока вы смотрите на мобильном приложении через WiFi, битрейт подстраивается под скорость подключения около 6 Мбит/с, а если вы выносите телефон за его пределы, качество падает до SD. Без DRM нельзя, это запрещено договорами с правообладателями. Хотя некоторые фильмы защищать не надо в основном, те, которые считаются частью мирового наследия. Фильмы с оригинальной дорожкой у нас есть, но я не могу сказать точно, сколько их.

Работаете архитектором и CTO одновременно?


Да. Я рос в Okko от разработчика на Android до full stack, back end, архитектора, системного архитектора и CTO. Мне нравится заниматься архитектурными вещами. Я стал CTO 3 года назад, и это развязало мне руки: теперь я могу комфортно и быстро продвигать новые технологии, которые я сам вместе с нашей командой архитекторов считаю нужными, необходимыми, перспективными.

Сейчас я продолжаю решать архитектурные вопросы по новым кускам системы и по расширению старых кусков. Техническая команда Okko еще год назад составляла не больше 40 человек, и на каждую платформу приходилось немного (мы работаем с мобильными Apple и Android, смарт-ТВ, Web и так далее); при том, что для работы с клиентами и тестирования нужно 10-15 человек, а также люди нужны на DevOps, поддержку облачной инфраструктуры, разработку серверного ПО и различных внутренних (backoffice) инструментов, не видных пользователю. На малое количество людей приходится большая плотность знаний и для того, чтобы правильно развивать систему дальше, нужно правильно привлекать эти знания. Я стараюсь максимально делиться своими собственными знаниями.

Разделяются ли эти роли?


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

Будет ли сравнение Okko с аналогичными сервисами?


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

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


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

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


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

Я вот вначале подумал что въедливая, умная и капризная аудитория Хабра не входит в целевую группу Okko, потом сообразил, что как раз таки входит, а нецелевая группа смотрит обычное ТВ, а не шарится по стриминговым сервисам.
Если бы Okko пошло по пути тех же трекеров в плане предоставления контента то есть, с возможностью выбора нюансов, озвучки, качества то результат мог бы быть хорошим, за удобство доступа вполне можно было бы платить. Почему вы так не делаете?


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

Почему в разделе аниме 50 фильмов, и только один от Миядзаки?


Честно скажу, меня это тоже возмущает. И я уверен, что наш отдел контента слышит наши стенания и уже работает над этим.

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


Киноклуб это совместный просмотр? У нас есть такие идеи, сейчас идет исследование студенческий рисерч-проект, чтобы попробовать. А театральные и режиссерские версии уже есть, если их поискать.

Почему в России нет своего Netflix, который бы продюсировал кино?


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

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

Реально ли иметь сервис, где будут ВСЕ любимые фильмы? Не хочу 10 подписок


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

Почему нельзя сделать подписку как у Netflix, в которую входит все?


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

Некоторые кинотеатры требуют несколько подписок одновременно: для основного контента и для сериалов от HBO, например. Почему?
Это история, которая диктуется правообладателями в противном случае они вообще не дадут контент. Тут мы сами в ловушке.

Почему даже в премиум-подписку не входят все фильмы?


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

Откуда берутся цены на фильмы?


Оттуда же, из контрактов. Плюс затраты на маркетинг и другие наценки.

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


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

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

Почему такая высокая цена? Оптимум с ширпотребом 399, премиум в два раза дороже 799, и то отдельные фильмы приходится докупать


Это больно, но я не знаю что на это сказать такое ценообразование.

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

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

На новинки обычно хожу в кино, но иногда люблю смотреть старые фильмы. В Кинопоиске они входят в подписку, и половину он дает посмотреть бесплатно (с рекламой), а в Okko такого нет. Почему?


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

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

Почему некоторые сезоны сериалов платные при наличии подписки в Okko? У меня часто бесплатен по подписке только первый сезон


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

Фильмы в 4К только платные. Почему так?


На самом деле нет, есть подписка 4К. Она входит в Премиум.

Почему нельзя отказаться от фильмов, которые не могут быть включены в подписку, и/или сотрудничать с правообладателями?


Потеря денег.

У Netflix нет платных фильмов, можно по подписке смотреть все, что доступно


Да, но зато у них нет The Other Lamb.

Почему у нас нигде нет так, как на Netflix?


Ну, пока нет. Боремся с пиратством. Каждая копеечка важна с точки зрения выживания сервиса.

Наше население неплатежеспособно, сравните уровни жизни за рубежом и здесь вот и ответ на пиратство?


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

Кинопоиск охватывает сторонние студии озвучки, разрешает матюки, ценник ниже, делает свои проекты, нет путаницы с подписками, что предпринимает Okko?


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

Правда ли, что, чем больше сервисов, тем больше шансов, что на них кто-то подпишется?


Не знаю. Думаю, выживает несколько подписок в итоге.

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


Да, мы все это будем делать, это вопрос взаимоотношений с правообладателем и правил работы с индустрией. Голливуд он такой, жестокий.

Почему приставка Okko Smart Box продается с обрезанным функционалом? Чтобы получить AndroidTV, приходится шаманить


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

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

Стоковая прошивка запускает Youtube в FullHD. Зачем там начинка, которая годится для 4K, но не показывает 4K?


Я думаю, в этом году будет обновление приложения Okko для Smart Box, в котором будет 4K. Это, опять же, вопрос лицензирования. Чтобы получить разрешение на показ фильмов от Disney или Warner в 4К, нужен технический аудит устройства командой по защите контента на предмет наличия лицензированного DRM например, Microsoft PlayReady, Google WideVine, Apple FairPlay и еще нескольких. Они должны быть реализованы с хранением ключей не в памяти приложений, а в hardware trusted zone то есть, чтобы защищенность обеспечивалась на уровне железа, а декодированное видео тоже защищалось на уровне железа вплоть до выхода HDMI, где будет работать HDCP, который покажет черный экран при подключении китайского сплиттера. Smart Box еще не прошел лицензирование, но процесс идет вот это вот 4К лицензирование в том числе находится и в моих руках и я этим обязательно займусь, завтра утром ;).

Что планируется по спорту? Новый ЧМ по футболу, Лига чемпионов, другие виды?


Сейчас я как раз стараюсь больше сосредотачиваться на спорте. Там более интересные технологии, на мой взгляд; кроме того, в этой области можно развиваться наравне со всем миром. Понятно, что Okko и остальные отечественные игроки сильно отстают от Netflix в области фильмов, но, если говорить о спортивных over-the-top трансляциях, то Okko не насколько отстает от ESPN+, например, как от Netflix. У нас есть шансы догнать и определять этот рынок. 17 июня рестартует Премьер-лига, там будут варианты просмотра в оригинале (с пустым стадионом), либо с наложением звуков стадиона. Приостановленный MLS американская лига обычного футбола тоже будет возрождаться. Других футбольных лиг пока не предполагается, потому что это требует серьезного расширения штата комментаторов; они у нас круты, но для одновременной трансляции итальянского и испанского чемпионата потребовалось бы больше людей и за эти кадры пришлось бы бороться с Матч-ТВ. Другие виды спорта будут, возможно до конца года.

Иногда приложение Okko запускается на телевизоре LG минут 10, а ivi стабильно быстро, почему?


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

Почему Okko не может сделать нормальное приложение для телефона?


Есть долг по мобильному Android, но мы над ним работаем. Приложение для Apple, как мне кажется, нормальное.

Почему в некоторых сезонах сериалов на PlayStation не работает звуковая дорожка? Почему версия для Android не запоминает тайминг и номер серии?


Должна запоминать. Напишите нам об этом, мы исправим. Возможно, что это Android 4.4 и у него специфика сложная поищем.

Общее качество приложения отвратительно, почему не смогли повторить, имея перед глазами Amazon Prime и Netflix?


Сейчас техническая команда Okko порядка ста человек. У Netflix года два назад было 600 человек, плюс отдельная команда человек 200, которые занимаются рекомендациями (у нас пять человек). Будем развиваться.

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


Я довольно подробно коснулся этого и рассказал, с техническими деталями, на конференции HighLoad++ в конце прошлого года. Доклад доступен на Youtube и в виде PDF. Выводы были сделаны, платформа была улучшена.

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

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

Как дела с приложением Okko Спорт на Xbox?


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

Что за фигня с региональными дорожками и сабами? То есть, то нет, в разных приложениях по-разному


Это из-за разницы в форматах. Существует три основных.

Стрим MPEG Dash стандарт, в нем вроде бы должны все работать, в нем используется Common Encryption DRM. Работают все-таки не все: его поддерживают основные браузеры, но не Safari, также новые платформы смарт-ТВ: Samsung, LG (после 14-го года).

Еще есть Microsoft SmoothStreaming с DRM PlayReady, его поддерживают более старые платформы смарт-ТВ. Для Safari есть HLS с Apple FairPlay. Для Android MPEG Dash с DRM WideVine. Есть некоторые устройства, где MPEG Dash используется с PlayReady от Microsoft; более старый вариант PlayReady + Smooth Streaming, еще более старый WideVine Classic (например, для старых LG).

Такая фрагментация стримов. Live еще более чувствителен к деталям в манифестах. На HighLoad я рассказывал о том, как базовые Live-энкодеры и пакеджеры тестируются у больших вендоров вроде Amazon: при этом используются только новые платформы, типа LG и Samsung после 14-го года, а на старые им плевать. Мы исследовали этот вопрос и понимаем, как поправлять манифесты, чтобы все работало; мы написали модуль для Nginx, который меняет их на лету для старых платформ.

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


Мы работаем над этим.

Алексей: было много жалоб на приложение для PlayStation, выношу в отдельный рассказ о нашей работе в Sony


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

Когда к Sony пришла компания Okko и сказала, что хочет разместить приложение на PS3 и PS4, нам сказали: вот WebMAF, пусть там крутится ваше HTML-приложение. Мы много усилий потратили на попытки уговорить Sony предоставить нам доступ к тому же API, которым пользуются геймдевы, но нам его не дали.

Дальше мы настраивали работу нашего Javascript/HTML через этот устаревший Web-движок. Я уже говорил, что Netflix может диктовать всем условия так вот, им этот доступ Sony дали, у них приложение работает на их движке, который они контролируют.

На PS5, которая должна была выйти этой осенью, этот вопрос вроде бы улучшен и существует доступ к различным SDK для HTML-приложений. Еще там больше памяти JS-приложение на PS4 вылетает именно из-за ее недостатка. Но, пока PS5 не вышла, мы ничего не можем сделать. Netflix работает на PS на том же уровне, что и игры, поэтому работает идеально.

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

Почему сервис на PS4 только в 1080p?


4K просто не помещается в выделенную память на PS4.

Добавьте UFC на Okko. И пусть попробуют заняться организацией боев или спонсорством боев на манер РенТв, лично мня это интересует больше футбольчика


Не буду раскрывать все карты спойлерить.

Планируется ли закупать контент у стриминговые сервисов, недоступных на территории РФ?
Amazon Prime и Netflix не продают так свой контент.


Если бы они продавали, мы бы закупили.

Почему выбор качества в зависимости от платформы, на которой смотришь? Один сервис заявляет, что есть 4К, но его можно смотреть только на телевизорах от LG
Это связано со стримами. 4К это HEVC/265, нужен MPEG Dash + Common Encryption. Это как раз поддерживают новые телевизоры от LG/Samsung и Android TV. Старые смарт-ТВ не поддерживают HEVC.

Есть проблемы на устройствах, на которых нормально смотрю другой 4K-контент. Почему так?
Да, есть сложности из-за того, что DRM шифрование-дешифрование добавляет необходимости в ресурсах. Из-за этого может не работать стриминг, которому требуется HEVC и DRM даже в тех случаях, когда работает другой 4К-контент (mp4).

На какие технологии в IT следует обратить внимание тем, кто заканчивает ВУЗы в ближайший год? Что будет актуально в ближайшие 5 лет?


Сейчас актуально дробление.

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

Можно найти хорошие переведенные книги, есть отличный сайт microservices.io.

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

В ближайшие годы явно будут актуальны облачные сервисы. У нас не так много людей владеет построением решений на Amazon Web Services, например в этом стоит прокачиваться. Хотя есть облака Mail.RU, Yandex или Sbercloud, они отстают от AWS и даже от Google Cloud или Azure.

Почему для Казахстана недоступен весь контент?


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

Что будет с моей истекшей из-за covid-19 подпиской на Премьер-лигу?


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

Честно платить за контент у меня получается только за игры, ПО и музыку, остальные медиа у нас еще в каменном веке по уровню сервиса. Почему?


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

Как принять участие к киноклубе?


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

Как вы поддерживаете высокую доступность сервиса? У вас, как у Youtube, есть какие-то коробочки для провайдеров?


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

Сколько сил вкладывается в web?


Постепенно все больше. Там много маркетинговых историй, и дальше эта платформа будет развиваться. Хотя раньше я в неё даже и не верил по мне, web = rutracker.

Почему нет возможности выбрать аудио дорожки и включить субтитры?


На некоторых фильмах они есть, хотя и не на всех. Мы работаем над этим.

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


Исходный файл добывается не так просто. Кроме того, это довольно ограниченная ниша спроса, хотя мы, конечно, расширяем каталог фильмов с такой озвучкой и субтитрами. У нас сейчас есть бэк-каталог, который мы долго кодировали в тех форматах стримов, о которых я раньше упоминал Dash, PlayReady/Smooth Streaming и так далее. Некоторое время назад мы начали использовать новый подход к подготовке контента: теперь мы кодируем один раз и используем just-in-time-преобразования для разных типов стримов. У нас эта технология уникальна, как я думаю, но Netflix тоже так делает; собственно, здесь каждый изобретает свой велосипед. Свой бэк-каталог мы перекодировали, но не всегда можно найти хороший исходник с оригинальной дорожкой. Надо понимать, что тайминг может не совпадать: даже видеоряд у оригинала и локализации немного отличается из-за разной длины реплик, например, и такая синхронизация требует дополнительной работы отдела контента а этот отдел и так постоянно загружен добавлением фильмов.

Тяжело ли общаться с российскими правообладателями?


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

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

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


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

И это нужно было превратить в наши мегабиты в секунду; потребовалось серьезно напрячься, чтобы успеть в срок. Можно еще вспомнить вопросы нагрузки, кодирования just-in-time в разные стримы, sale architecture чтобы клиенты ходили на разные back-end сервера, чтобы размазывать нагрузку и потенциальные сбои.

Какие языки стоит учить? Хочу Python и Java


Хорошие языки. Хотя нужные вещи на Python можно переписать на Go, а на Java на Kotlin. В Kotlin больше синтаксического сахара, можно вместить 10 строк на Java в одну на Kotlin конечно, на первый взгляд она будет совершенно непонятна.

На Go я пока серьезно не работал.

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

Как развиваться разработчику, чтобы стать архитектором?


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

Не надо бояться это то же самое программирование, тестирование, инженерия.

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

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

Дальше мы стали писать приложения под Apple, часть переквалифицировалась под Objective-C; дальше Windows Phone. Потом я стал изучать вещи под backend хотелось, чтобы API было лучше. Мне стало понятнее, как взаимодействуют большие компоненты между собой, какая боль у клиентов, как ее решать через backend. От этого выросло мое архитектурное мышление но это только один из вариантов пути. Можно приходить через test-driven development, например.

Зачем брать подписки, если то и дело из них пропадают фильмы и сериалы?


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



А что дальше?


Следующий прямой эфир пройдет во вторник, 23 июля, в 20:00.
Маркетолог RUVDS Сания Галимова будет отвечать на ваши вопросы в прямом эфире. Эфир пройдет в нашем инстаграм-аккаунте.

Задать ей вопрос можно в комментариях к этому посту.



Что было ранее


  1. Илона Папава, Senior Software Engineer в Facebook как попасть на стажировку, получить оффер и все о работе в компании
  2. Борис Янгель, ML-инженер Яндекса как не пополнить ряды стремных специалистов, если ты Data Scientist
  3. Александр Калошин, СEO LastBackend как запустить стартап, выйти на рынок Китая и получить 15 млн инвестиций.
  4. Наталья Теплухина Vue.js core team member, GoogleDevExpret как пройти собеседование в GitLab, попасть в команду разработчиков Vue и стать Staff-engineer.
  5. Ашот Оганесян, технический директор и основатель DeviceLock кто ворует и зарабатывает на ваших персональных данных.



Подробнее..

Как стать тимлидом фронтендеров и как жить после этого расшифровка эфира

27.06.2020 14:19:52 | Автор: admin
15 июня в нашем инстаграм-аккаунте прошел прямой эфир с Ильей, руководителем фронтенд-разработки в Яндекс.Деньги. Выкладываем запись эфира и расшифровку.



Меня зовут Илья, я работаю в компании Яндекс.Деньги и руковожу фронтендом. До этого был бэкенд-разработчиком, писал на C#, около 5 лет назад перешел во фронтенд. Чуть больше года руковожу. Вот такой путь развития. Еще активно участвую в Burning Lead это сообщество для ведущих разработчиков, тимлидов, людей, которые так или иначе пересекаются с задачами управления; надеюсь, ребята из сообщества слушают стрим.


Про Node.js и его использование


Сначала скажу, как она у нас появилась и почему мы ею пользуемся. Исторически сложилось так, что у нас в Деньгах есть полноценный Java-бэкенд, в котором Java-разработчики работают с базами данных, с основной бизнес-логикой. Фронтендеры с бизнес-логикой не работают, мы подготавливаем для себя нужный формат данных и отправляем его на фронтенд, а там уже рисуем их на каком-либо фреймворке. Изначально у нас был Xscript-сервер, который ребята в Яндексе сделали еще в 2000-х годах это наше legacy. Часть логики серверный рендеринг мы писали на XML, XSL/XML преобразования. Так продолжалось очень долго. Потом, когда мы осознали, что разработчиков на XSL/XML стало тяжело искать, мы стали выбирать новый сервер, в который можно было бы писать на бэкенде и потом использовать на фронтенде. Оказалось, что есть целая платформа Node.js.

Тогда Node.js была очень молодой платформой, версия 0.10, наверно. Решено было использовать ее по нескольким причинам: язык Javascript набирал популярность, разработчиков было много; кроме того, серверную и клиентскую логику мог писать один разработчик без суперспецифичных знаний. О своем выборе мы не жалеем: платформа все еще активно развивается, оптимизируется, становится быстрее, получает полезные фичи, имеет активное сообщество.

Поговорим про архитектуру фронтенда и о том, чего мы хотели бы достичь в архитектуре Яндекс.Денег в целом. Так как мы используем Node.js, у нас уже долгое время основой серверного фреймворка служит Express. Он хорошо справляется со своей задачей обрабатывает запросы пользователя и дает ответы, больше от него ничего не нужно. Для него написано множество плагинов. Есть SSR для React-приложений, например; так как основной стек на клиенте это React, SSR не проблема прикрутить. Есть много реализаций; можно даже не писать код: разворачиваешь из NPM, он сам все делает.

Что касается архитектуры мы порядка 4-5 лет живем на Express, и из-за этого возникают некоторые проблемы. У нас довольно много разработчиков в отделе сейчас человек 50 и нам нужно писать понятный для всех код; разработчики могут менять интересы, переходить из команды в команду, и нам нужно, чтобы код был примерно одинаковым, чтобы разработчик в новой команде не тратил по месяцу на акклиматизацию к новому коду. Express довольно низкоуровневый фреймворк, и с ним живется довольно тяжело: каждая команда использует свое видение того, как писать обработчики запросов или бизнес-логику, ходить в бэкенд. Первая попытка наладить архитектуру сервера была совершена, когда мы сделали ProcessFlow. Я на эту тему выступал с докладами рассказывал, как на основе IDEF0 можно построить систему, которая позволит организовать бизнес-логику, задать правила ее написания, сделать поддержку, визуализацию связей между сущностями. Попытка была вполне успешной: в некоторых местах у нас были серьезные проблемы с пониманием кода, и ProcessFlow помогла их решить. Она работает и сейчас, и вполне нас устраивает.

Сейчас у нас идет переезд на NestJS. Это довольно современный серверный фреймворк, позволяет писать контроллеры в парадигме Model-View-Controller, организовывать бизнес-логику; его философия пришла из Angular. Его сильная сторона это правила, они уже на уровне фреймворка определяют написание контроллеров и бизнес-логики. Бесконтрольная среда бывает губительна, когда вас много и все пишут по-разному; лучше иметь свод правил, к которому всегда можно обратиться такой путь мы выбираем. Про NestJS активно рассказывает мой коллега Андрей Мелехов, ведущий подкаст devSchacht; он сейчас описывает процесс переезда на NestJS, обсуждает проблемы.

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

Про клиентскую часть


Она состоит из двух больших стеков. Первый это легаси-стек с использованием методологии BEM Naming (определенные названия CSS-стилей, позволяющие избегать пересечений), на основе которой в Яндексе создали фреймворк. Мы использовали его довольно долго, так как мы используем технологический стек Яндекса. Он классный, и в нем работа с компонентами организована примерно так же, как в современных фреймворках: в виде отдельно лежащих блоков, которые удобно поддерживать. Однако он уже устарел, поскольку основан на GQL и не отвечает современным требованиям по UI; на нем очень сложно делать анимации и приложения на клиенте. Мы постепенно переходим на React уже несколько лет (переход продвигается тогда, когда меняется дизайн или функциональность: то есть, все переписывания бизнес-процессов происходят на новой технологии). Он показался нам довольно мейнстримовым то есть, разработчиков на нем много. React основной фреймворк на клиенте, в качестве стейт-менеджера используется Redux; с ним же мы используем Redux-Thunk для асинхронных действий и запросов к бэкенду. В нескольких проектах использовали hooks.

Почему не Angular?


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

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


На самом деле, в каждой компании будут собственные требования к тимлиду или руководителю отдела, но, как мне кажется, есть и определенный план того, что нужно знать и делать, чтобы развиваться в направлении менеджмента. Есть такой подкаст PodlodkaPodcast, они публиковали такой план (роадмап). Крутая штука; там написано, что следует читать для развития нужных softskills на них нужно делать упор. Конечно, у хорошего тимлида должны быть и отличные hardskills: он не просто формальный лидер команды (допустим, 5 человек), он должен доказать свое лидерство, он должен учить свою команду, его люди должны желать научиться программировать так же, как может он. Но важны и softskill: коммуникативные навыки для общения в пределах команды и вне их, для отстаивания мнения команды, для поиска компромиссов. В работе тимлида очень много коммуникаций. Кроме того, нужно уметь проявлять эмпатию: при общении с разработчиками важно устанавливать понимание на уровне чувств, понимать настроение каждого собеседника, определять, чего он хочет. Напрямую это не говорится, но очень хорошо, когда тимлид владеет этим. Здорово, когда к hardskills также прилагается умение наставничества: за таким тимлидом потянутся люди, он будет в состоянии четко формулировать и ставить задачи.

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

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

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

О процессах управления людьми в нашем отделе


Процесс разработки подразумевает общение разработчиков между собой, и у нас есть несколько точек пересечения. Задача на разработку поступает в одну из команд; обычно команда это Java-разработчики, фронтенд-разработчики, менеджер, продукт, обязательно тестировщики. Такая единица, сидит где-то отдельно. Существование других команд для нее особенного значения не имеет само по себе но нам необходимо, чтоб все команды писал приблизительно единообразный код. Для этого нужно общаться, и здесь есть несколько подходов. Во-первых, это происходящие время от времени встречи всего отдела; сейчас мы все собираемся в zoom, но это, конечно, не то. На встречах мы делимся новостями, ребята рассказывают, что они делают у себя в командах: какие у них проекты, какие будут в дальнейшем, что и как они делают. Это помогает строить представление о том, что происходит во фронтенде: он большой, просто так его рассмотреть не выйдет. Еще мы организуем tech talks, разные по масштабам: на всю компанию или на наш отдел, и там представляются технические приемы: например, на одном из них рассказывали, как используются hooks в React, как они влияют на форму, как выглядит код для них, какие плюсы и минусы. Такие доклады интересно слушать, и они помогают распространять по компании знания.Непосредственно в разработке есть процессы, которые позволяют нам общаться так, чтобы писать код, который потом не встретит непонимания на кодревью из-за используемых приемов, компонентов и библиотек то есть, мы стараемся нивелировать плохие последствия от изолированного принятия решений. Этот процесс, который мы называем Logic Review, позволяет нам узнавать мнения экспертов, ведущих разработчиков, старших разработчиков после того, как мы понимаем, как делать определенную задачу то есть, сверить наше видение реализации проекта с видением тех, кто определяет дальнейшее развитие всего отдела. Он позволяет нам обмениваться знаниями, технологиями, и контролировать однородность и архитектуру стека. Конечно, успеть везде и избежать всех проблем на кодревью невозможно, но такая сверка перед началом разработки позволяет уменьшить их количество.

Можно ли обмануть Review 360?


Напомню, что Review 360 это когда все (разработчики, тестировщики, менеджеры), с кем работал человек, которого нужно оценить, опрашиваются по кругу с помощью опросника. Я об этом процессе рассказывал на Burning Lead. Если команда небольшая, как у нас обычно человек 5-10 то этот процесс, собственно, не нужен: тимлид может сам пообщаться с каждым членом команды. Собственно, он и должен общаться с каждым разработчиком раз в 1-2 недели, чтобы понимать, чего хочет разработчик, какое у него настроение, доволен ли он задачами, как он работает, как проходит его рост. Но, когда команда большая например, у меня сейчас больше 50 фронтендеров то на такое личное общение уже не будет хватать времени. У тимлида есть и другие обязанности и проекты, он обязан развивать отдел, он не может тратить все рабочее время только на общение, которое впоследствии нужно будет еще и проанализировать. Поэтому приходится использовать менее точные подходы например, Review 360.

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

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

Расскажите про менеджер зависимости, composer и Laravel


Я знаю, что Laravel хороший PHP-фреймворк, и у нас на нем пишут, но сам с этими технологиями почти не работал.

У вас есть разделение на верстальщиков и JS-разработчиков, или разработчик делает все?


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

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


К сожалению, сейчас у нас нет открытых вакансий для джунов, но они бывают. Мы требуем знания теории языка Javascript. Это может показаться абсурдным, потому что теория JS в повседневных задачах вроде бы не нужна; однако мы знаем, что человек, изучивший теорию, умеет работать с информацией и воспринимать её. Кроме того, у него есть мотивация: он сел и разобрался с тем, как язык работает; когда он сталкивается с проблемой или сложным местом, он знает, как искать нужную для решения информацию (даже гуглить надо уметь).

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


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

Какой размер вашей команды?


У меня две роли в компании: я руковожу отделом порядка 50 человек и одновременно являюсь product owner нашей платформенной команды, там 8 человек.

React Native или Flutter?


У нас были эксперименты с React Native, Flutter тогда был очень новым; мы решили, что выберем React Native.

Яндекс хочет свой фрейм запускать?


Нет, BEM это очень старый фреймворк, он устарел, мы вместо него используем React. Никто не хочет запускать новый фреймворк.
Вопрос: на бэкенде только JS, или есть какие-то legacy-части?
Я рассказывал, что у нас есть сервер с Xscript с XML/XSL. Это как раз и есть наше legacy, мы его активно выпиливаем и хотим как можно скорее прекратить его использовать. В основном в 96% случаев у нас используется JS.

Redux-Thunk или Redux-Saga?


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

Вы внутри компании или команды ставите задачи по Smart?


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

Насчет микросервисов сейчас выкатили Module Federation Pack 5, можно ли в эту сторону посмотреть?


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

В чем разница в управлении 5, 10 и 50 людьми?


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

Будет ли массовый переход на NestJS?


Сложно сказать. Может, завтра появится новый фронтенд-фреймворк, превосходящий NestJS, и мы все будем на него переходить. Я думаю, что сейчас NestJS хорошо проработан, но нужно исходить из задачи. Для многих задач, которые мы решаем на Node, не нужен такой серьезный фреймворк например, для лямбда-функций, которые кто-то будет вызывать; но, когда на фронтенде есть развесистая логика, кажется, что подошел бы лучше Nest. Он сейчас хорошо проработан, есть и бэкенд-фреймворк (хотя он был довольно сырым, когда мы смотрели его). Nest развивается и, может быть, станет более популярным, но я не думаю, что будет массовый переход на него, как на Express.

Чем отличаются собеседования на джуна и миддла? Что оценивается во втором случае?


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

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


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

Как строите процесс по управлению таким количеством человек? Сколько лидов? Тяжело ставить цели?


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

Проводите 1 на 1? Как часто? Лайфхаки?


Собственно, у нас в компании ревью как раз называется 1 на 1. Сейчас я провожу со всеми старшими разработчиками ревью раз в месяц (это реже, чем рекомендуется лучше проводить раз в пару недель). Зачастую нам есть, что обсуждать. Лайфхаков особых нет в литературе достаточно подробно расписано про 1 на 1. Важно давать разработчику говорить он должен говорить примерно 80% времени; в этом суть: задача руководителя создать на ревью дружественную и безопасную атмосферу, чтобы разработчик мог ему рассказать все, что его беспокоит. Это довольно тяжело и не всегда получается, но круто, если 1 на 1 есть, и на них есть, что обсуждать. Их лучше проводить в неформальной обстановке например, можно в парке. Создание комфортной атмосферы может быть разным это не только переговорка в офисе.

Какие вакансии у вас открыты?


В каком направлении? У нас довольно много в разных направлениях. По фронтенду мы ищем нескольких миддл-разработчиков (по-моему, 2), можно и senior.

Какие сложные задачи возникают у руководителя?


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

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


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

Что делать, если тимлид слабоват и явно не должен оставаться на позиции?


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



А что дальше?


30 июня в 20:00 в нашем инстаграм-аккаунте будет выступать Влада Рау Senior Digital Analyst в лондонском офисе McKinsey Digital Labs. Сейчас Влада занимается product/data engineering. До своего переезда в Лондон она дважды стажировалась в Google в Дублине, а также училась в ВШМ СПбГУ и IE Business School в Мадриде.

Задать ей вопрос можно в комментариях к этому посту.



Что было ранее


  1. Илона Папава, Senior Software Engineer в Facebook как попасть на стажировку, получить оффер и все о работе в компании
  2. Борис Янгель, ML-инженер Яндекса как не пополнить ряды стремных специалистов, если ты Data Scientist
  3. Александр Калошин, СEO LastBackend как запустить стартап, выйти на рынок Китая и получить 15 млн инвестиций.
  4. Наталья Теплухина, Vue.js core team member, GoogleDevExpret как пройти собеседование в GitLab, попасть в команду разработчиков Vue и стать Staff-engineer.
  5. Ашот Оганесян, технический директор и основатель DeviceLock кто ворует и зарабатывает на ваших персональных данных.



Подробнее..

Стандартизация разработки ПО

22.06.2020 04:18:32 | Автор: admin
Первый шаг к совершенствованию это стандартизация. Там, где нет норм, не может быть улучшения.

Канбан и точно вовремя на Toyota




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

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

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



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

В первой компании, назову её Diversity, разработчики постоянно пробуют технологические новинки и любят поспорить друг с другом о преимуществах разных технологий. Одна команда пишет на TypeScript и использует React, вторая команда предпочитает JavaScript без типизации и использует Vue (подставьте здесь свои любимые технологии и фреймворки).

Во второй компании, пусть это будет Standard & Co, решили стандартизировать разработку и всё пишут на одном стеке с подробным регламентом разработки, пусть это будет React и Flow (типизированный JavaScript).

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

Общие проблемы и общие решения


Стандартизация стека


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

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

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

Если речь идёт о разработке с нуля, Standard & Co сможет разделить работу между командами, в Diversity обеим командам придётся выполнить весь объём самостоятельно.

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

Отсюда мораль: единый стек первый шаг к стандартизации разработки ПО.

Шаблон приложения


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

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

Standard & Co опять впереди с точки зрения общей производительности, они устранили расход времени на решение повторяющихся задач.

Мораль: стандартная архитектура экономит время.

Библиотека стандартных решений


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

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

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

Обе компании пришли к одному выводу: использование библиотек готовых решений высвобождает время разработчиков для реализации бизнес-логики, т.е. создания ценности для заказчика. Но в Standard & Co обнаружили ещё и некоторые дополнительные эффекты от использования общей библиотеки. Читайте далее!

Тестирование


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

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

Ротация проектов и людей


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

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

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

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

Планирование


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

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

Рост компании


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

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

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

Контроль за разработкой и ревью кода


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

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

Эффективное общение


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

Разработчики Standard & Co после таких разговоров идут дорабатывать общий для них код. Помогая себе, разработчики помогают и другим, и наоборот. Ещё после недавнего набора новых разработчиков в Standard & Co проводят обучающие мероприятия. Раз в неделю кто-то из разработчиков разбирает технический вопрос из ежедневной практики, теперь можно с пользой для дела в рабочее время поговорить на общие темы.

Модернизация и быстрые технологические улучшения


Ещё одно преимущество стандартизации Standard & Co обнаружила после выхода новой версии языка TypeScript. Она показалась разработчикам удобнее для разработки, чем Flow, который они уже давно использовали. Разработчики Standard & Co переписали шаблон приложения и библиотеку компонентов интерфейса на TypeScript, сделав разработку проще, а код лаконичнее.

Сколько бы команд не было у компании, после обновления общих шаблонов и библиотек новый функционал сразу становится доступным для всех и проходят разностороннюю обкатку и тестирование. Инициатива о модернизации может исходить от любой из команд, за актуальностью стека в Standard & Co следит уже коллективный разум.

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

Негативные эффекты стандартизации


Потеря квалификации


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

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

Стандартизация может негативно повлиять на уровень программистов.

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

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


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

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

Отклонения от стандартов источник прогресса и ошибок


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

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

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

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

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

Стандартизация не происходит сама


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

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

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



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

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

7 cмертных грехов Slack в большой компании (и как победить их автоматизацией)

19.06.2020 12:20:11 | Автор: admin
Так как многие, похоже, останутся на удаленке на лето, Slack станет центром пересечения буквально всех процессов и коммуникаций. Хотим поделиться набором мини-приложений, которые помогут решать типовые проблемы разных команд.


Например, вы можете сделать себе бота, который будет будит CTO.

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

1. Люди спрашивают все подряд и делятся субъективно важными вещами в основном канале


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

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

В Slack есть своя версия этого греха зайти в канал #general и спросить что-нибудь почти личное. Плюс вишенка на торте тегнуть всех.

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

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

  • При попытке написать в #general бот моментально удаляет пост из канала но для автора это незаметно: кажется, что тебе просто не дают опубликовать сообщение. При этом робот сохраняет текст и данные об авторе.
  • Бот напоминает, зачем нужен канал и предлагает подумать, стоит ли писать именно в него.
  • Если автор упорствует, бот отправляет текст на проверку модератору.
  • Дальше модератор обычно это кто-то из внутреннего PR или опубликует текст в канале, указав автора оригинала, или напишет автору в личку, объяснит, почему его сообщение нерелевантно каналу, и где лучше публиковать такие запросы или новости.

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

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


2. Никто не читает закреп перед тем, как написать в канал


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

Скажем, вы вбиваете в поиске что-то вроде #mobile, чтобы найти, где поделиться замечанием или предложением по работе одного из приложений. И видите примерно такой список:


С недавних пор завели правило неактивные в течение 90 дней каналы архивируются.

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


Раньше мы указывали типы запросов, которые можем обработать, в закрепленном сообщении. Но (surprise!) его никто не читал.

Теперь у нас есть бот, который присоединяется к каналу и при добавлении любого новичка отправляет ему эфемерное (это которое 'Only you can see this message') сообщение с правилами.

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


3. Задают вопросы, которые есть во внешнем FAQ. И вообще не любят выходить во внешние информационные системы


На этот счет мы написали целый взвод ботов. Каждый помогает в своем кейсе.

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


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

Мы поступили просто: если кто-то не идет в вики, то она должна прийти к нему. Так как вопросы часто типовые, написали бота, который:

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


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


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


Общение команд разработки и инфраструктуры идет через канал, в который за день падают по 30-50 сообщений. Ребятам из инфры есть чем заняться, помимо создания тикетов в Jira. Поскольку любое сообщение в канале #infra будет или запросом, или отчетом о проблеме, есть бот, который автоматически создает таски из сообщений вида привет, вот-что-случилось-или-нужно, помогите, пожалуйста.


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

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

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


5. Тратят время на ручную выгрузку и визуализацию данных из внешних систем


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

Slack-burndown-bot берет спринт в Jira и формирует диаграмму сгорания: вот сколько всего задач, вот сколько вы сделали, вот сколько осталось.


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

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

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


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


6. Говорят, ну я же написал вот там... или Бот, который может разбудить CTO


Иногда бывает такое, что что-то легло. Особенно, ночью.

Для критичных падений мы завели отдельный канал и подключили к нему бота, который дублирует дежурного. Мы используем сервис Opsgenie для алертинга: говоришь ему следить за набором серверов и, если какой-то упал, то сервис присылает дежурному сообщение на пейджер звонит дежурному на мобильный. Если дежурный не реагирует, спустя 20-30 секунд ему звонит робот и когда трубка поднята, робот сообщает что-то вроде: Там лежит, ужас, нажмите 1, если вы это услышали и чините.


Процесс на гифке ускорен, но отражает суть.

Если человек не поднял трубку или не нажал 1, это эскалирует звонок до его тимлида.
А если и тимлид недоступен, звонок может эскалироваться вплоть до технического директора.

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


7. А еще все хотят своего бота для слэка


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

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

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

Code review в Gitlab CE если Merge request approvals нет, но очень хочется

24.06.2020 18:08:11 | Автор: admin

Одной из самых нужных функций, которой нет в бесплатной версии GitLab, является возможность контролировать Merge request (MR), используя обязательный code review.

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



Зачем это вообще?



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

В итоге приходится:
  • либо совсем запрещать Merge в защищенные ветки для части разработчиков, но тогда разработчики, имеющие право на Merge, получают конфликты при слиянии чужих MR как бонус;
  • либо давать возможность делать бесконтрольные слияния с вашей мастер-веткой без code review, даже если это Junior, устроившийся только вчера.


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

Общая схема работы



В качестве примера настроим Merge request approvals на тестовом репозитории myapp
gitlab.com/gitlab-ce-mr-approvals/myapp

  1. Создадим токен для доступа к API GitLab (через него будем получать информацию о количестве голосов за и против)
  2. Добавим токен в переменные GitLab
  3. Запретим Merge при ошибках в пайплайне (если голосов за недостаточно)
  4. Настроим проверку голосов как часть пайплайна CI/CD
  5. Запретим делать коммиты в защищенные ветки, все изменения проводим только через MR
  6. Проверим, что получилось в итоге


1. Создаем токен для доступа к API



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


Учетная запись для получения токена
Доступ к API позволяет делать практически все с вашими репозиториями, поэтому советую создать отдельную учетную запись Gitlab, дать ей минимальные права на ваши репозтории (например, Reporter) и получить токен для этой учетной записи.



2. Добавляем токен в переменные Gitlab



Например, на предыдущем шаге мы получили токен QmN2Y0NOUFlfeXhvd21ZS01aQzgK

Открываем Настройки CI/CD Переменные Добавить переменную GITLAB_TOKEN_FOR_CI



В итоге получим:



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

3. Ставим запрет на Merge, если не получены одобрения коллег после проведенного code review



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

Заходим в Настройки Основные Запросы на слияние Проверки слияния и включаем опцию Сборочные линии должны успешно выполниться


4. Настраиваем пайплайн



Если вы еще не делали CI/CD конвейер для вашего приложения
Создаем в корне репозитория файл .gitlab-ci.yml с простейшим содержанием

stages:  - build  - testvariables:  NEED_VOTES: 1include:  - remote: "https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml"run-myapp:  stage: build  script: echo "Hello world"




Отдельный репозиторий для конфигурации CI/CD
Я бы рекомендовал сделать отдельный репозиторий, в котором необходимо создать файл myapp.gitlab-ci.yml для настройки конвейера. Так вы сможете лучше контролировать доступ участников, которые могут изменить конвейер сборки и получить токен доступа.

Расположение нового файла конвейера нужно будет указать, зайдя в репозиторий myapp Настройки CI/CD Сборочные линии Пользовательский путь конфигурации CI указать новый файл, например myapp-ci.gitlab-ci.yml@gitlab-ce-mr-approvals/ci


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

Пример контейнеров с линтерами, которые вы можете встроить в ваш пайплайн:
hub.docker.com/r/gableroux/gitlab-ci-lint
hub.docker.com/r/sebiwi/gitlab-ci-validate

И пример стадии проверки:

stages:  - lintlint:  image: sebiwi/gitlab-ci-validate:1.3.0  variables:    GITLAB_HOST: https://gitlab.com  script:    - CI_FILES=(./*.yml)    - for f in "${CI_FILES[@]}"; do        gitlab-ci-validate $f;      done;




Осталось добавить в ваш пайплайн несколько параметров, чтобы все заработало:

stages:
- test

variables:
NEED_VOTES: 1

include:
- remote: "https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml"


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

include подключает стадию test, проверяющую количество лайков.

Простейший пайплайн на примере myapp.gitlab-ci.yml
stages:
- build
- test

variables:
NEED_VOTES: 0

include:
- remote: "https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml"

run-myapp:
stage: build
image: openjdk
script:
- echo CI_MERGE_REQUEST_TARGET_BRANCH_NAME $CI_MERGE_REQUEST_TARGET_BRANCH_NAME
- java HelloWorld.java



Содержание check-approve.gitlab-ci.yml
ci-mr:
stage: test
script:
- echo ${CI_API_V4_URL}
- echo "CI_PROJECT_ID ${CI_PROJECT_ID}"
- echo "CI_COMMIT_SHA ${CI_COMMIT_SHA}"
- "export MR_ID=$(curl --silent --request GET --header \"PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI\" ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests | jq \".[] | if .sha == \\\"${CI_COMMIT_SHA}\\\" then .id else {} end\" | grep --invert-match {})"
- "export MR_TITLE=$(curl --silent --request GET --header \"PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI\" ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests | jq \".[] | if .sha == \\\"${CI_COMMIT_SHA}\\\" then .title else {} end\" | grep --invert-match {})"
- "export MR_WIP=$(curl --silent --request GET --header \"PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI\" ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests | jq \".[] | if .sha == \\\"${CI_COMMIT_SHA}\\\" then .work_in_progress else {} end\" | grep --invert-match {})"
- "export MR_UPVOTES=$(curl --silent --request GET --header \"PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI\" ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests | jq \".[] | if .sha == \\\"${CI_COMMIT_SHA}\\\" then .upvotes else {} end\" | grep --invert-match {})"
- "export MR_DOWNVOTES=$(curl --silent --request GET --header \"PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI\" ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests | jq \".[] | if .sha == \\\"${CI_COMMIT_SHA}\\\" then .downvotes else {} end\" | grep --invert-match {})"
- MR_VOTES=$(expr ${MR_UPVOTES} - ${MR_DOWNVOTES})
- NEED_VOTES_REAL=${NEED_VOTES:-1}
- echo "MR_ID ${MR_ID} MR_TITLE ${MR_TITLE} MR_WIP ${MR_WIP} MR_UPVOTES ${MR_UPVOTES} MR_DOWNVOTES ${MR_DOWNVOTES}"
- echo "MR_VOTES ${MR_VOTES} Up vote = 1, down vote = -1, MR OK if votes >=${NEED_VOTES_REAL}"
- if [ "${MR_VOTES}" -ge "$(expr ${NEED_VOTES_REAL})" ];
then
echo "MR OK";
else
echo "MR ERROR Need more votes";
exit 1;
fi
image: laptevss/gitlab-api-util
rules:
- if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master" || $CI_MERGE_REQUEST_TARGET_BRANCH_NAME =~ /^release\/.*$/'



Подробнее о том, что происходит при проверке:
  • установлено ограничение, что проверка будет только при создании MR в ветки master или release/*
  • используя API GitLab, получаем количество лайков и дизлайков
  • вычисляем разность между положительными и отрицательными откликами
  • если разность меньше заданного нами значения в NEED_VOTES, то блокируем возможность сделать слияние


5. Запрещаем коммиты в защищенные ветки



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

Для этого заходим в Настройки Репозиторий Protected Branches


6. Проверяем



Зададим NEED_VOTES: 0

Делаем MR и ставим дизлайк.



В логах сборки:


Теперь ставим лайк и запускаем повторную проверку:
Подробнее..

Статический анализ baseline файлы vs diff

25.06.2020 12:16:27 | Автор: admin

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


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



baseline или так называемый suppress profile


Этот метод имеет несколько названий: baseline файл в Psalm и Android Lint, suppress база (или профиль) в PVS-Studio, code smell baseline в detekt.


Данный файл генерируется линтером при запуске на проекте:


superlinter --create-baseline baseline.xml ./project

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


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


superlinter --baseline baseline.xml ./project

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


Обычно, мы хотим достичь следующего:


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

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


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


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

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


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


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


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


Хорошо подобранный набор признаков увеличивает эффективность baseline подхода.


Коллизии в методе baseline


Допустим, диагностика W104 находит вызовы die в коде.


В проверяемом проекте есть файл foo.php:


function legacy() {  die('test');}

Предположим, используются признаки {имя файла, код диагностики, строка исходного кода}.


Наш анализатор при создании baseline добавляет вызов die('test') в свою базу исключений:


{  "filename": "foo.php",  "diag": "W104",  "line": "die('test');"}

Теперь добавим немного нового кода:


+ function newfunc() {+   die('test');+ }  function legacy() {    die('test');  }

По всем используемым признакам новый вызов die('test') будет распознаваться как игнорируемый код. Совпадение сигнатур для потенциально разных кусков кода мы и называем коллизией.


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


Что делать, если вызов die('test') был добавлен в ту же функцию? Этот вызов может иметь одинаковые соседние строки в обоих случаях, поэтому добавление предыдущей и следующей строки в сигнатуре не поможет.


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


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


Метод, основанный на diff возможностях VCS


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


Утилита revgrep принимает на stdin поток предупреждений, анализирует git diff и выдаёт на выход только те предупреждения, которые исходят от новых строк.


golangci-lint использует форк revgrep как библиотеку, так что в основе его вычисления diff'а лежат те же алгоритмы.

Если выбран этот путь, придётся искать ответ на следующие вопросы:


  • Как выбрать окно коммитов для вычисления diff?
  • Как будем обрабатывать коммиты, пришедшие из основной ветки (merge/rebase)?

Вдобавок нужно понимать, что иногда мы всё же хотим выдавать предупреждения, выходящие за рамки diff. Пример: вы удалили класс директора по мемам, MemeDirector. Если этот класс упоминался в каких-либо doc-комментариях, желательно, чтобы линтер сообщил об этом.


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


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


diff режим в NoVerify


NoVerify имеет два режима работы: diff и full diff.


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


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


Изначальная схема работы предполагалась такая: на pre-push хуках запускается более быстрый анализ, в режиме обычного diff'а, чтобы люди получали обратную связь как можно быстрее. На CI агентах полный diff. В результате время от времени люди спрашивают, почему на агентах проблемы были найдены, а локально всё чисто. Удобнее иметь одинаковые процессы проверки, чтобы при прохождении pre-push хука была гарантия прохождения на CI фазы линтера.


full diff за один проход


Мы можем делать приближенный к full diff аналог, который не требует двойного анализа кода.


Допустим, в diff попала такая строка:


- class Foo {

Если мы попробуем классифицировать эту строку, то определим её как "Foo class deletion".


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


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


Переименования не требуют дополнительной обработки. Мы считаем, что символ со старым именем был удалён, а с новым добавлен:


- class MemeManager {+ class SeniorMemeManager {

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


Выводы


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


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


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

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


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

Подробнее..

Восемь самых популярных книг по Agile, Scrum и Kanban

25.06.2020 14:15:14 | Автор: admin
Наша команда знакома с гибкими методологиями разработки, двухнедельные спринты наше все. Недавно руководство решило распространить наш опыт на другие подразделения и попросило нас помочь в этом деле. Трезво оценив обстановку, мы поспешно отказались от этого предложения, но обещали подкинуть литературы, чтобы коллегам было с чего начать.

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



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


Как растет спрос на гибкие методологии


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

Начнем с Agile:


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

А тут разбивка по месяцам. Особенно впечатляет пик в апреле, во время самоизоляции:


Ну а в июне уже чувствуется сезонный спад активности.

По Scrum похожая ситуация, где по годам наблюдается даже более быстрый рост:


Хотя по месяцам цифры достаточно ровные:


А вот с Kanban все скромнее: пять мероприятий в 2019 году и три за первые пять месяцев 2020 года.

Далее мы решили оценить, насколько активность в Точках соответствует общим тенденциям роста интереса к Agile-тематике.

Мы взяли яндексовский WordStat и посмотрели динамику числа запросов по соответствующим ключевым словам за последние полгода:


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

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


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

В поисках правильных критериев оценки


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

Вот так выглядит один из субъективных рейтингов, который нам встретился:
Лучшие книги по Agile, Scrum и Kanban, по версии одного из экспертов
ФИО автора
Название книги
1
Джефф Сазерленд
Scrum. Революционный метод управления проектами
2
Сборник
Канбан и точно вовремя на Toyota. Менеджмент начинается на рабочем месте
3
Майк Кон
Scrum: гибкая разработка ПО
4
Джефф Сазерленд, Кен Швабер
Софт за 30 дней. Как Scrum делает невозможное возможным
5
Дженнифер Грин, Эндрю Стиллмен
Постигая Agile
6
Зузана Шохова
Путь скрам-мастера
7
Майк Кон
Agile: Оценка и планирование проектов
8
Юрген Аппело
Agile-менеджмент. Лидерство и управление командами
9
Стивен Деннинг
Эпоха Agile


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

Вариант 1: посмотреть рейтинг книг по отзывам на сайтах, посвященных книгам. Их можно найти, например, на Litres.ru, Livelib.ru, Ozon.ru. Есть также сайт Bookmate.com, где пользователи отмечают, какие книги они прочитали, и оставляют рекомендации. Для нас интересно количество этих рекомендаций.

Если свести все данные в единую тепловую карту, получится вот такая картина.

Рейтинг книг на основании оценок пользователей специализированных сайтов


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

Продолжаем искать более объективные метрики.

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

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

Рейтинг книг на основании количества упоминаний


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

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

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

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

Вот что получилось:


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

Кратко расскажем о каждой из них.

1. Джефф Сазерленд. Scrum. революционный метод управления проектами




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

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


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

2. Канбан и точно вовремя на Toyota. Менеджмент начинается на рабочем месте




Это перевод учебных материалов специалистов компании Toyota к семинарам по производственной системе из далеких 1970-х годов. Как Сазерленд по Scrum является своеобразным евангелием, так и эта книга стала точкой отсчета для Kanban-подхода.

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


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

3. Майк Кон. Agile: Оценка и планирование проектов




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

Подход многих руководителей проектов можно представить как планирование, планирование, планирование выполнение. Agile-подход это планирование выполнение адаптация, планирование выполнение адаптация. Чем выше неопределенности проекта, тем важнее применение agile-подхода для успеха.


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

4. Дженнифер Грин, Эндрю Стиллмен. Постигая Agile




Этот объемный труд (450 страниц) включает в себя описание всех основных agile-методологий: Scrum, Kanban, Lean и XP (eXtremal Programming). Книга легко читается, методологии даются несколько поверхностно, в обзорном режиме.

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


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

5. Хенрик Книберг. Scrum и XP: заметки с передовой




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

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


Книга небольшая, в сети можно найти перевод, сделанный энтузиастами из Agile Ukraine.

6. Борис Вольфсон. Гибкое управление проектами и продуктами




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

Закон Паркинсона: любая работа увеличивается в объеме, чтобы заполнить все отпущенное на нее время.


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

7. Майк Кон. Scrum: гибкая разработка ПО


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

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


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

8. Дэвид Андерсон. Канбан. Альтернативный путь в Agile




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

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


Стоит обратить внимание, что здесь Kanban рассматривается в разрезе разработки ПО, что делает книгу полезной именно для ИТ-продуктологов, разработчиков и руководителей проектов.

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

Перевод Трехступенчатый фреймворк для решения проблем

26.06.2020 18:17:05 | Автор: admin


От автора перевода

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



Уверен, что с аналогичными проблемами сталкивается абсолютное большинство продуктовых компаний. В качестве рабочего инструмента для решения этих проблем полезным представляется подход, описанный в статье Ленни Рачитски, product lead Airbnb.

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

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


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

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



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

  • Шаг 1. Кристаллизация проблемы
  • Шаг 2. Согласование проблемы с командой и стейкхолдерами
  • Шаг 3. Постоянный возврат к проблеме



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

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



Шаг 1. Кристаллизация проблемы


Начните с ответа на эти вопросы о своем проекте.

  • Описание: что это за проект?
  • Проблема: какую проблему он решает?
  • Почему: как мы поняли, что это реальная проблема и ее нужно решать?
  • Успех: как мы узнаем, что проблема решена?
  • Аудитория: для кого мы делаем это?
  • Что это: как будет выглядеть реализация в продукте?

Описание: что это за проект?


Это краткое описание идеи. Люди, читающие его, смогут быстро понять суть. Будьте кратки.

Проблема: какую проблему он решает?


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

Назовем ключевые характеристики правильной постановки проблемы.

  1. Проблема кратка. Цель описать проблему одним предложением. Чем больше вам требуется объяснений, тем менее ясной становится проблема в конечном итоге.
  2. Сфокусирована. У нас есть единственная ясная проблема, которая может быть решена одной командой и в разумные сроки. Часто очень полезно привести несколько примеров других проблем, которые вы НЕ решаете.
  3. Связана с неудовлетворенной потребностью. Сосредоточьтесь на потребностях пользователя или бизнеса. Тут крайне полезно использовать вот этот фреймворк.
  4. Включает ответы на вопрос что и почему. Что идет не так и почему это проблема? Возможно, вам придется вернуться сюда в следующей секции.
  5. Не зависит от решения. Подавляйте в себе желание слишком быстро перейти к решению проблемы.

Хорошие примеры постановки проблемы

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

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

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

Почему: как мы поняли, что это реальная проблема и ее нужно решать?


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

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

Несколько советов для этого шага.

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

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

Успех: как мы узнаем, что проблема решена?


Вы достигли того, что планировали достичь? Как вы узнаете? Ответьте на этот вопрос и запишите ответ.



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

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

Несколько советов для определения критериев успеха.

  • Постарайтесь получить конкретное число, например: 10% прирост показателя X; 50% уменьшение показателя Y.
  • Цель должна быть достижима, но амбициозна. Достижение какой цели приведет вашу команду и руководителей в восторг?
  • Если вы не смогли придумать метрику для своей цели (думать нужно долго и напряженно), опишите, как будет выглядеть мир в случае успеха проекта. Сделайте это критерием успеха.

Аудитория: для кого мы делаем это?


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

Что: как будет выглядеть реализация в продукте?


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

Шаг 2. Согласование проблемы с командой и стейкхолдерами


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



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

Я обычно подхожу к этому шагу так.

  1. Возьмите документ, созданный на первом этапе (это может сделать и любой член вашей команды, вовлеченный в эту проблему).
  2. Поделитесь им со всей командой. Соберите обратную связь. Доработайте документ с учетом полученной обратной связи и снова предоставьте его на общее обозрение.
  3. Если обратная связь сходится и команда выглядит синхронизированной отлично. Если нет, соберите всех вместе и обсудите разногласия.
  4. Когда согласие внутри команды будет достигнуто, синхронизируйтесь в понимании проблемы со стейкхолдерами. Важно, чтобы ваша команда и люди, которые будут оценивать результаты, одинаково понимали проблему, которую вы решаете, до того, как вы плотно приступите к работе по проекту.
  5. Соберите команду и снова произведите ревью постановки проблемы. Отыщите ответы на нерешенные вопросы и убедитесь, что у команды есть все необходимое, чтобы начать работать.

Шаг 3. Постоянный возврат к проблеме


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

image

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

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

Избежать этой ловушки помогут полезные привычки.

  1. При каждом ревью проекта удостоверьтесь, что исполнитель начинает с постановки проблемы. Если это не очевидно, задайте вопрос: Какую проблему мы пытаемся решить?.
  2. При каждом отчете о ходе проекта перед стейкхолдерами возвращайтесь к постановке проблемы. Убедитесь, что у всех остается одинаковое ее понимание.
  3. Перед финализацией проекта спросите себя: Чувствую ли я уверенность в том, что мы готовы решить проблему, которую планировали решить изначально?.

И в заключение


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

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

Марк Менсон. Тонкое искусство пофигизма

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

Очень рекомендую прочитать следующие 5 книг.



  1. Deep Work (Кэл Ньюпорт. В работу с головой. Паттерны успеха от IT-специалиста)
  2. The Subtle Art of Not Giving a F*ck (Марк Менсон. Тонкое искусство пофигизма)
  3. Good Strategy, Bad Strategy (Ричард Румельт. Хорошая стратегия, плохая стратегия. В чем отличие и почему это важно)
  4. Measure What Matters (Джон Дорр: Измеряйте самое важное. Как Google, Intel и другие компании добиваются роста с помощью OKR)
  5. Lean Analytics (На момент написания статьи не переведена на русский)

От автора перевода

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




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

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

Тимлиды. Много и сразу. Как выбрать и развивать

26.06.2020 18:17:05 | Автор: admin
Всем привет! Меня зовут Андрей Новиков, я руководитель разработки в одном из подразделений компании Exness, и совместно с Леной Скворцовой, нашим HR BP, мы хотим вам рассказать про то, как выбираем тимлидов в командах разработки, как их развиваем и как растим под жарким кипрским солнцем.



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


Наша инфографика на 01/06/2020

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

  1. Найм сотрудников на Кипр всегда происходит медленнее, чем в СНГ, так как для многих релокация это серьезный шаг.
  2. В один момент нанять 79 тимлидов непростая задача, которая растянется на годы.
  3. Для наших инженеров стать тимлидом еще один путь развития, который позволяет ребятам, желающим в будущем занимать менеджерскую позицию, расти внутри компании.
  4. Этапы шторминга и притирания проходят гораздо быстрее с человеком, которого команда уже знает.

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

  1. Процесс выбора;
  2. Talentpool;
  3. Программа развития;
  4. IDP;
  5. Уроки и советы.


Процесс выбора


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

Для этого весь процесс мы разделили на несколько этапов:

  1. Самостоятельная подготовка;
  2. Собеседование;
  3. Калибровка результатов.




Самостоятельная подготовка


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

Собеседование


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

  1. Какая мотивация у сотрудника стать тимлидом? Деньги, карьера, вызов, саморазвитие, признание?
  2. Какие сильные стороны есть у кандидата для роли тимлида?
  3. Что необходимо прокачать и изменить?
  4. Какие риски есть при назначении данного сотрудника на роль тимлида? Например, команда останется без единственного фронта, и нужно сразу открывать позицию на замену, или есть риск сильной демотивации другого кандидата?

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

Калибровка результатов


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

Talent Pool


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

Программа развития


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

Программа базового менеджмента



  • Развитие лидерства команды
    • Роли менеджмента
    • Цикл управления
    • Ситуационное лидерство
  • Навыки влияния
    • Управление вовлеченностью
    • Типы личностей
    • Избегание манипуляций
  • Навыки влияния и оценка деятельности
    • 1-1 встречи
    • Оценка 360
    • Как предоставлять негативный фидбек
  • Управление собственной продуктивностью
    • Приоритеты
    • Типы планирования
    • Энерджи-менеджмент
  • Мотивация
    • Мотивация или вовлечение
    • Теория мотивации
    • Gallup Q12

Программа операционного менеджмента


  • Инцидент менеджмент;
  • Гибкие методологии разработки (Scrum, Kanban);
  • Фасилитация встреч;
  • Процесс найма;
  • Процесс адаптации;
  • Увольнение;
  • Разбор сложный кейсов;
  • Зарплата.

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

IDP (Individual Development Plan)


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

Процесс составления и развития по IDP выглядит так:

  1. Подготовка. На первичной встрече тимлид и Learn & Development (L&D) специалист/ HR обсуждают те области, где сотрудник чувствует неуверенность/ хочет расти. Это беседа с примерами из ежедневной работы руководителя, цель которой понять, что конкретно хочется улучшить. Как в идеале выглядит результат? Чем это поможет бизнесу?

  2. Составление IDP. IDP это список книг, статей, подкастов, видео, фильмов, активностей для прокачки конкретного скилла. На каждый скилл, как правило, включаем чтение/ видео/ активность, чтобы, как говорится, и в теории, и на практике.
  3. Развитие. После того, как IDP готов, мы приступаем к работе над ним. Один раз в месяц тимлид и L&D специалист/ HR встречаются, чтобы посмотреть, работает ли IDP, стоит ли его подкорректировать, и чем еще можно помочь. IDP это рабочий инструмент, который может меняться и дополняться. Например, после результатов 360 мы часто дополняем IDP, если видим, что конкретная компетенция просела.

Как выбрать компетенции для IDP? Задача L&D специалиста и тимлида на первой встрече понять на примерах, какая компетенция нуждается в улучшении.
Обычно все компетенции в IDP попадают в три основные области скиллов в компании: business acumen (понимание бизнеса и отрасли), operational excellence (execution) и leadership (soft skills, так необходимые руководителю). Для тимлидов первая версия IDP в основном заключалась в работе над leadership, а именно people management.
Как мы измеряем прогресс? Как всегда фидбек! Это и личный фидбек от коллег, и результаты 360, и, конечно же, отзывы тимлидов про свое развитие.



Уроки и советы


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

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

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

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

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

02.07.2020 18:23:23 | Автор: admin

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


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



Дано: продуктовая команда удаленщиков с почасовой ставкой, выстроенными и отработанными процессами пятый месяц работает над MVP мобильного приложения в сфере geo-dating. Работа движется по плану, в соответствии с согласованными требованиями, с еженедельными демо-показами без критических отставаний по срокам. Команда сильная, все ребята из топовых IT-компаний. Координатор со стороны инвестора, не технический человек, помогает нам в административных делах и коммуникацией с инвестором. Я выступаю в роли проджект/продакт менеджера, отвечаю за реализацию продукта, его качество и соответствие ожиданиям инвестора. Казалось бы, все более-менее идеально, через месяц должен быть первый публичный релиз.


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


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


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


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



Шаг 1. Внутреннее умиротворение


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


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


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


Шаг 2. Принятие


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


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


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


Шаг 3. Сохранение целостности команды и ограждение от деструктивного воздействия


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


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


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


Шаг 4. Обеспечение максимальной открытости и доброжелательности к новоприбывшим


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


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


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


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


Шаг 5. Утверждение обязанностей


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


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


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


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


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


Шаг 6. Интеграция в процессы


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


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


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


Шаг 7. Определение канала влияния


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


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


Шаг 8. Переход к совместной работе


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


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


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


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


Я с остатками команды выделила задачи, которые можно делать без back-enda. Благо, они обгоняли клиентскую часть по решаемым задачам.


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


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



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


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


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


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


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


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



Шаг 9. Работа над продуктом


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


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


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


Шаг 10. Подведение итогов


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


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


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


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


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


Выводы


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


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


Безвыходных ситуаций нет, есть тернистые пути, которые приходится проходить.


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


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

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

Подробнее..

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

03.07.2020 14:20:11 | Автор: admin
Мы в команде обожаем настолки. И чем сложнее их механика, тем интереснее.

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

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



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

Что для нас означают командные бест-практики


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

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

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


Команда, когда я прошу ее помнить про договоренности с ретро

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

Набор карт и правила


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

Проклятие: Соплежуй
Разыграй эту карту на больного человека. Немедленно отправь его домой.

Проклятие: Покорми QA
Отдай тому, кто не прогнал автотесты по своей ветке перед передачей в тестирование.

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

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

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

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

Проклятие: Скорострел
Отдай тому, кто перевёл таску в тестирование до окончания ревью. Игрок должен выполнить сокровенное желание QA.

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

Гонг
Разыграй эту карту после дейли. Вся команда встает и идет на обед.

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

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

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

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

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

Черная дыра
Играй, если PO передал dev-команде не готовую к проработке историю. Команду засосет черная дыра, а история вернется к PO или UX.

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

Проклятие: Полиамория
Играй в пару FE и BE, чтобы они начинали интегрироваться (можно безопасно на заглушках).

Подкупи стейкхолдеров
Можешь не рассказывать о фейлах на спринт-ревью.

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

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

Правила игры

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

Раздаем карты


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



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

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

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

При этом большую часть карт разыграть не удалось. Первая проблема была в том, что мы раздавали их рандомно. Кажется, по аналогии с Манчкином стоило добавить классы Фронтендер, Бэкендер, QA. Если бы на Ассенизаторе было написано Только для QA, он бы попал к ребятам, которые в нем заинтересованы. К тому же все случаи с не запущенными автотестами точно пройдут через них, а разработчики с такой картой на руках могли про них даже и не знать.

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

Какой вывод мы сделали


Как минимум, это весело! Было интересно всем вместе придумывать механику, особенно в таком стебном стиле. И оказалось интересно попробовать, как она работает.

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

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

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

Scrum и Fixed Price в аутсорсинге совместить нельзя разделить

06.07.2020 12:10:38 | Автор: admin
Мало кто находит выход, некоторые не видят его, даже если найдут, а многие даже не ищут.
Из Алиса в стране чудес

В статье поднимаются следующие вопросы.

  1. О противоречивости компонентов аутсорсинговой формулы Scrum + Fixed Price.
  2. Об одной, из возможных, ошибке (корневой причине), предшествующей неверному выбору инструмента Scrum.
  3. Об одной ситуации, когда действительно стоит вопрос о совмещении Scrum и Fixed Price, требующий глубокого анализа и поиска компромиссов для ее разрешения.


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




Как говорилось в статье С чего начинается псевдо-Scrum в аутсорсинге, в большом количестве аутсорсинговых проектов, команды которых совмещают (или, не исключено, выдают желаемое за действительное) Scrum и Fixed Price, не верно идентифицирован жизненный цикл (ЖЦ) проекта. Т.е. совершена ошибка в выборе между итеративным инкрементным или гибким ЖЦ. И, как результат, не верно выбран управленческий инструмент фреймворк Scrum. И уже следствием этого выбора является возникновение ряда проблем, неверных выводов об Agile, Scrum и попыток (от слова пытка?) совместить эти два взаимоисключающих понятия.

Взаимоисключающих?!

Сейчас аргументирую.

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

Scrum + Fixed Price это то же самое, что идти одновременно вперед и назад?


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


При заключении контракта на оказание аутсорсинговых услуг клиент практически всегда настаивает на Fixed Price (схема под ключ). Его пожелание зафиксировать Product Scope (или объем работ), увидеть бюджет, сроки. Он хочет видеть, что покупает. На Time & Material клиенты соглашаются редко.

Таким образом, ключевой момент: потребность клиента зафиксировать в контракте, а провайдера услуг выполнить обязательства по контракту и гарантировать, что параметры будут неизменными с прогнозируемой погрешностью (в силу некоторой степени неопределенности и рисков на этапах продаж и заключения контракта) после начала разработки. Вопрос понижения степени неопределённости и рисков это вопросы возможности проведения и качества фазы Discovery (Pre-sale, диагностики) в отношении Product Scope.

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

Fixed Price просто обязывает нас поставить в приоритет управление планом. Иначе, зачем нам что-то фиксировать, заведомо зная, что оно изменится, и мы на самом деле не планируем этим управлять? Чтобы просто заключить контракт? Критическая ошибка устоявшихся процессов продаж: фиксируем, заведомо зная, что будем менять, лишь для того, чтобы подписать контракт!

Почему будем менять? Потому что Scrum это ведь всегда про неопределённость и ее результат изменения. Это про приоритет управления изменениями. И ведь не исключено, что они могут появиться уже после первого спринта. Почему?

Отступление о возможных причинах изменений

В чем может быть причина изменений? Она, например, может быть в некачественно проведенной фазе Discovery (Pre-sale, диагностики) в ситуации, когда Product Scope может быть определен в той или ной мере (для примера см. п. 3 из Case Study в статье), но по каким-то причинам этого не сделано. В таком случае, это проблема фазы и внутренних процессов, а не причина выбора Scrum для контракта с Fixed Price, гибкого ЖЦ вместо итеративного с целью компенсации допущенной ошибки.

Хотя, справедливости ради, отмечу, что в продажах (Pre-sale-активностях бизнес-аналитиков) в аутсорсинге (одна из самых проблемных фаз с точки зрения Product Scope!) не все так просто как в магазине, когда покупается готовый товар с конкретными свойствами (функциональностью). А фаза Discovery сложно продаваемая активность бизнес-аналитиков и команды. Но минимизация в той или иной степени неопределенности и оценка рисков одна из главных задач грамотно выстроенного процесса продаж. Как и формирование понимания у клиента о необходимости и важности этих активностей (бывает очень сложно!). Но для этого существует достаточное количество техник и инструментов. И это сводится к вопросу качества оказываемых услуг, а не продажи кота в мешке.

Другая причина может быть в невозможности определить Product Scope & Vision на текущий момент (для примера см. п. 2 из Case Study в статье). И это действительно очень непростая и невыгодная для обеих сторон ситуация, когда возникает серьезное противоречие и поднимается вопрос о совмещении Scrum и Fixed Price при оказании аутсорсинговых услуг. Она требует тщательного анализа, дополнительных действий по формированию всестороннего понимания клиента (зачастую технически и идеологически далекого от реалий процессов разработки) о возможных сложностях и рисках и поиску компромиссных решений.

Итак, почему же выбирается Scrum? Чтобы управлять изменениями, которые, например, возникают в результате неверно проведенной фазы Discovery (Pre-sale, диагностики) либо когда Product Scope не может быть определен на данной фазе? В первом случае, на мой взгляд, это ошибочно. Во втором сложно реализуемо при Fixed Price.

Третий возможный вариант выбора Scrum как инструмента Agile, гибкого ЖЦ вместо итеративного инкрементного в ситуации, когда Product Scope проработан и зафиксирован на фазе Discovery (Pre-sale, диагностики), а в контракте Fixed Price, тоже на мой взгляд не рационален: зачем выбирать инструмент для управления изменениями (уводить из фокуса явно более приоритетную вещь план), когда их вероятность минимизирована?

Возращение к главной мысли статьи.

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

Но контракт с Fixed Price задает приоритет в управлении планом!

Таким образом формула Scrum + Fixed Price трансформируется в управление изменениями + управление планом одновременно. Задача менеджера управлять в разных степенях и планом, и изменениями, но в приоритете может быть только что-то одно: либо план, либо изменения.

Либо управление планом, либо управление изменениями это, своего рода, аксиома, заложенная в основы менеджмента и бизнес-анализа. Она отражена в базовых (и не только) руководствах для менеджеров (PMBOK) и бизнес-аналитиков (BABOK). А классификация ЖЦ (и их идентификация в отношении конкретных проектов) опирается на нее: есть ЖЦ, предназначенные для управления планом (например, Waterfall, итеративные инкрементные (IID)) и гибкие, Agile для управления изменениями. Выбор ЖЦ (а в последствии и инструментов) строится из того, чему в управлении отдается приоритет.

Гибкий ЖЦ это разновидность итеративного инкрементного ЖЦ для проектов с определенными доминирующими признаками/особенностями (список контрольных вопросов приведен в вышеназванной статье), позволяющими идентифицировать его как отдельный ЖЦ и направить все силы на управление изменениями. К этим признакам могут быть отнесены: невозможность здесь и сейчас достичь некоторой степени определенности Product Scope (самое важное!), поиск бизнес-решения (или его быстрая поставка бизнесу для формирования обратной связи), которое выстрелит, формирование списка ключевых функций продукта (Key Features), короткие итерации, изменчивость, эксперимент, постепенное наращивание функционала, ретроспективы, совершенствование не только продукта, но и процессов с целью получить лучший вариант продукта. Возможно ли в таких условиях получить адекватные оценки бюджета и сроков?

Дьявол всего в одной детали или все дело в Product Scope


Во всем есть своя мораль, нужно только уметь ее найти!
Из Алиса в стране чудес

Что вы можете сказать об определенности (возможности ее установить) в отношении Product Scope & Vision на этапе продаж, фазы Discovery, на старте проекта в аутсорсинге?

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

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

В аутсорсинге чаще всего вопрос в первую очередь заключается в грамотном проведении фазы Discovery (Pre-sale, диагностики) в отношении Product Scope и выборе верного ЖЦ. И если выбирается Agile и Scrum в ситуации, когда Product Scope зафиксировать можно (и тем более, когда этого не было сделано по каким-то причинам вовремя, с ожиданием/предположением его проработки в будущем), и при этом в контракте Fixed Price, на мой взгляд, совершается ошибка, которая ставит под сомнение положительный исход проекта.

Спасибо за внимание!
Подробнее..

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

22.06.2020 18:15:30 | Автор: admin
Перевод статьи подготовлен в преддверии старта курса Team Lead 2.0.



Как я отмечал в статье Why metrics dont matter in software development unless you pair them with business goals", выбор метрик нужно продумывать очень тщательно, чтобы дать ответы на вопросы, которые ставит перед собой бизнес. Вот эта критическая точка: измерения должны быть спроектированы так, чтобы отвечать на вопросы бизнеса. И эти вопросы никогда не будут звучать как Сколько у нас сейчас тысяч строк кода в проекте?

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

Начните с измерения правильных вещей


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

Метрики Agile-процесса


Для agile и lean-процессов основными метриками будут leadtime, cycle time, velocity команды, и open/close коэффициент. Эти показатели помогают в планировании и принятии решений по улучшению процессов. Несмотря на то, что они не измеряют успешность или добавочную ценность, не имеют ничего общего с объективным качеством программного обеспечения, вам все равно нужно их отслеживать. Ниже я объясню почему.

  • Leadtime время, которое проходит от появления идеи до поставки программного обеспечения. Если вы хотите быстрее реагировать на нужды своих клиентов, работайте над уменьшением leadtime, зачастую посредством упрощения процесса принятия решений и сокращения времени ожидания. Leadtime включает в себя cycle time.
  • Сycle time количество времени, которое требуется на внесение изменений в систему ПО и доставку этих изменений на продакшн. Команды, использующие continuous delivery, могут измерять cycle time в минутах или даже секундах вместо месяцев.
  • Velocity команды количество единиц программного обеспечения, которое команда обычно выполняет в одну итерацию (спринт). Это число следует использовать только для планирования итераций. Сравнивать команды по показателю velocity идея бессмысленная, поскольку метрика основана на необъективных оценках. Рассматривать velocity как показатель успешности тоже бесполезно, да и постановка цели вроде придерживаться определенной velocity искажает ценность этой метрики для мероприятий по оценке и планированию.
  • open/close коэффициент количество появившихся и закрытых issue в единицу времени. Общая тенденция будет иметь большее значение, чем конкретные цифры.

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

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

Аналитика продакшена


  • Средняя наработка на отказ (Mean time between failures, MTBF)
  • Среднее время восстановления (Mean time to recover/repair, MTTR)

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

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

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

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

Помимо MTBF и MTTR, более точные метрики основаны на отдельных транзакциях, приложениях и т.д., и они отражают доставленную бизнес-ценность, а также стоимость устранения сбоев. Если ваше приложение для обработки транзакций падает один раз из ста, но при этом поднимается через 1-2 секунды без критических потерь информации, то и с частотой сбоев в 1% можно жить. Но если с такой частотой падает приложение, которое обрабатывает 100 000 транзакций в день, теряет по 100$ за сбой и восстановление стоит 50$, то исправление этого 1% будет в приоритете. И такое исправление в итоге сильно повлияет на итоговую ситуацию.

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


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

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

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

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

Вы найдете больше способов применения метрик безопасности в разработке программного обеспечения в статьях Application Security for Agile Projects и Security Threat Models: An Agile Introduction.

Заметка о метриках исходного кода


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

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

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

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

Соберем все вместе: Успех универсальная метрика


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

Как использовать метрики для достижения успеха


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

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

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

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

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

Как сформулировать ценностную гипотезу


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

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

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

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

Шесть эвристик для эффективного использования метрик


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

  1. Метрики не расскажут вам всю историю, а вот команда расскажет (снимаю шляпу перед Тоддом Декапула);
  2. Сравнивать снежинки это бесполезная трата времени.
  3. Вы можете измерить практически все, но не всему можете уделить внимание.
  4. Метрики успеха бизнеса способствуют улучшению программного обеспечения, а не наоборот.
  5. Каждая функция добавляет ценность, измеряете вы ее или нет.
  6. Измеряйте только те показатели, которые имеют значение в данный конкретный момент.

Еще





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

Как быть, когда все советуют растащить проект на микросервисы. А ты не готов

30.06.2020 12:04:28 | Автор: admin
Монолит часто обсуждают в негативном ключе. Но сразу перейти на микросервисы получится не у всех и вот уже не первая команда и компания делятся опытом построения переходного звена: модульной архитектуры. Давайте в деталях посмотрим, как делаются такие проекты.



Недавно я смотрел два доклада на эту тему: от Юлии Николаевой из iSpring и Антона Губарева из Skyeng. Так как с Антоном мы работаем в одной компании, для своего подкаста я решил поговорить с Юлей.



Ниже текстовая расшифровка основных идей из разговора.

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


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

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

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

Не было как такового нормального CI/CD, не было ни докера, ни кубернетеса вообще ничего такого.


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

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

У нас все усугублялось тем, что кусок легаси написан Symfony 1.4 с использованием Propel 2, который не так просто использовать в парадигме DDD (Domain Driven Design). А нам очень хотелось DDD. Для этого хорошо подходит ORM Doctrine, которую к легаси так просто не прикрутишь.

Мы решили скрестить ужа с ежом и теперь живем с двумя фреймворками.


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


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


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

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


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

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

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

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

На все у нас ушло, наверное, три с половиной месяца.


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

И ура! Мы можем писать фичи в 3-4 потока командой из 12 бэкендеров.


Сергей: В PHP мы не можем дать программисту по рукам и запретить использовать какой-то внутренний класс другого модуля. Это же все держится на устных договоренностях внутри команды. Как это все организовать?


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

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

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


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

Сергей: А как такую архитектуру мэйнтэйнить?

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

Сергей: БД у нас одна, проект у нас один. Что мне делать, если в моем модуле нужны данные из нескольких других контекстов?

Юлия: Это один из самых сложных вопросов наверное, как в модульной, так и в микросервисной архитектуре. Мы пытались в одном из случаев реализовать объединение данных из разных API: сделали запросы, объединение в памяти, сортировку, фильтрацию. Работало жутко медленно.

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

Сергей: И здесь мы подходим к проблеме с дублированием кода...

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

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

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

Все как в микросервисной архитектуре, грубо говоря.


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

Сергей: Но если приложение постоянно усложняется фичами и контекстами, модульный монолит все равно лишь промежуточный шаг к микросервисам?

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

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

P.S. Больше выпусков подкаста Между скобок с интересными людьми из мира PHP можно найти здесь.
Подробнее..

MLOps Cook book, chapter 1

03.07.2020 10:08:54 | Автор: admin


Всем привет! Я CV-разработчик в КРОК. Уже 3 года мы реализуем проекты в области CV. За это время чего мы только не делали, например: мониторили водителей, чтобы во время движения они не пили, не курили, по телефону не разговаривали, смотрели на дорогу, а не сны или в облака; фиксировали любителей ездить по выделенным полосам и занимать несколько мест на парковке; следили за тем, чтобы работники носили каски, перчатки и т.п.; идентифицировали сотрудника, который хочет пройти на объект; подсчитывали всё, что только можно.


Я все это к чему?


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


Моделируем ситуацию


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


  1. Наступает момент истины, нужно как-то вспомнить на чем ты остановился, какие гиперпараметры пробовал и, самое главное, к каким результатам они привели. Может быть множество вариантов, кто как хранил информацию по всем запускам: в голове, конфигах, блокноте, в рабочей среде в облаке. Мне довелось видеть вариант, когда гиперпараметры хранились в виде закомментированных строк в коде, в общем полет фантазии. А теперь представьте, что вы вернулись не к своему проекту, а к проекту человека, который покинул компанию и в наследство вам достался код и модель под названием model_1.pb. Для полноты картины и передачи всей боли, представим, что вы еще и начинающий специалист.
  2. Идем дальше. Для запуска кода нам и всем кто будет с ним работать необходимо создать окружение. Часто бывает, что и его нам в наследство также по каким-то причинам не оставили. Это тоже может стать нетривиальной задачей. На этот шаг не хочется тратить время, не так ли?
  3. Тренируем модель (например, детектор автомобилей). Доходим до момента, когда она становится очень даже ничего самое время сохранить результат. Назовем ее car_detection_v1.pb. Потом тренируем еще одну car_detection_v2.pb. Некоторое время спустя наши коллеги или мы сами обучаем ещё и ещё, используя различные архитектуры. В итоге формируется куча артефактов, информацию о которых нужно кропотливо собирать (но, делать мы это будем позже, у нас ведь пока есть более приоритетные дела).
  4. Ну вот и всё! У нас есть модель! Мы можем приступать к обучению следующей модели, к разработке архитектуры для решения новой задачи или можем пойти попить чай? А деплоить кто будет?

Выявляем проблемы


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



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


  • удобно хранить результаты работы;
  • сделать простым процесс вовлечения новых сотрудников;
  • упростить процесс развертывания среды разработки;
  • настроить процесс версионирования моделей;
  • иметь удобный способ валидации моделей;
  • найти инструмент управления состоянием моделей;
  • найти способ доставки моделей в production.

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


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


Можете почитать, что обо всем этом думают ребята из Google. Из статьи понятно, что MLOps, довольно, объемная штука.



Далее в своей статье я опишу лишь часть процесса. Для реализации я воспользуюсь инструментом MLflow, т.к. это open-source проект, для подключения необходимо небольшое количество кода и есть интеграция с популярными ml-фреймворками. Вы можете поискать на просторах интернета другие инструменты, например Kubeflow, SageMaker, Trains и т.д., и возможно, подобрать тот, который лучше подходит под ваши нужды.


"Cтроим" MLOps на примере использования инструмента MLFlow


MLFlow это платформа с открытым исходным кодом для управления жизненным циклом ml моделей (https://mlflow.org/).


MLflow включает четыре компонента:


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

MLflow оперирует двумя сущностями:


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

Все шаги примера реализованы на операционной системе Ubuntu 18.04.


1. Разворачиваем сервер


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


  • backend store отвечает за хранение информации о зарегистрированных моделях (поддерживает 4 СУБД: mysql, mssql, sqlite, and postgresql);
  • artifact store отвечает за хранение артефактов (поддерживает 7 вариантов хранения: Amazon S3, Azure Blob Storage, Google Cloud Storage, FTP server, SFTP Server, NFS, HDFS).

В качестве artifact store для простоты возьмем sftp сервер.


  • создаем группу
    $ sudo groupadd sftpg
    
  • добавляем пользователя и устанавливаем ему пароль
    $ sudo useradd -g sftpg mlflowsftp$ sudo passwd mlflowsftp 
    
  • корректируем пару настроек доступа
    $ sudo mkdir -p /data/mlflowsftp/upload$ sudo chown -R root.sftpg /data/mlflowsftp$ sudo chown -R mlflowsftp.sftpg /data/mlflowsftp/upload
    
  • добавляем несколько строк в /etc/ssh/sshd_config
    Match Group sftpg ChrootDirectory /data/%u ForceCommand internal-sftp
    
  • перезапускаем службу
    $ sudo systemctl restart sshd
    

В качестве backend store возьмем postgresql.


$ sudo apt update$ sudo apt-get install -y postgresql postgresql-contrib postgresql-server-dev-all$ sudo apt install gcc$ pip install psycopg2$ sudo -u postgres -i# Create new user: mlflow_user[postgres@user_name~]$ createuser --interactive -PEnter name of role to add: mlflow_userEnter password for new role: mlflowEnter it again: mlflowShall the new role be a superuser? (y/n) nShall the new role be allowed to create databases? (y/n) nShall the new role be allowed to create more new roles? (y/n) n# Create database mlflow_bd owned by mlflow_user$ createdb -O mlflow_user mlflow_db

Для запуска сервера необходимо установить следующие python пакеты (советую создать отдельное виртуальное окружение):


pip install mlflowpip install pysftp

Запускаем наш сервер


$ mlflow server  \                 --backend-store-uri postgresql://mlflow_user:mlflow@localhost/mlflow_db \                 --default-artifact-root sftp://mlflowsftp:mlflow@sftp_host/upload  \                --host server_host \                --port server_port

2. Добавляем трекинг


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


Для примера я создал небольшой проект на github на Keras по сегментации всего, что есть в COCO датасете. Для добавления трекинга я создал файл mlflow_training.py.


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


def run(self, epochs, lr, experiment_name):        # getting the id of the experiment, creating an experiment in its absence        remote_experiment_id = self.remote_server.get_experiment_id(name=experiment_name)        # creating a "run" and getting its id        remote_run_id = self.remote_server.get_run_id(remote_experiment_id)        # indicate that we want to save the results on a remote server        mlflow.set_tracking_uri(self.tracking_uri)        mlflow.set_experiment(experiment_name)        with mlflow.start_run(run_id=remote_run_id, nested=False):            mlflow.keras.autolog()            self.train_pipeline.train(lr=lr, epochs=epochs)        try:            self.log_tags_and_params(remote_run_id)        except mlflow.exceptions.RestException as e:            print(e)

Здесь self.remote_server это небольшая обвязка над методами mlflow.tracking. MlflowClient (я сделал для удобства), с помощью которых я создаю эксперимент и запуск на сервере. Далее указываю куда должны сливаться результаты запуска (mlflow.set_tracking_uri(self.tracking_uri)). Подключаю автоматическое логирование mlflow.keras.autolog(). На данный момент MLflow Tracking поддерживает автоматическое логирование для TensorFlow, Keras, Gluon XGBoost, LightGBM, Spark. Если вы не нашли своего фреймворка или библиотеки, то вы всегда можете логировать в явном виде. Запускаем обучение. Регистрируем теги и входные параметры на удаленном сервере.


Пара строк и вы, как и все желающие, имеете доступ к информации о всех запусках. Круто?


3. Оформляем проект


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


name: flow_segmentationconda_env: conda.yamlentry_points:  main:    parameters:        categories: {help: 'list of categories from coco dataset'}        epochs: {type: int, help: 'number of epochs in training'}        lr: {type: float, default: 0.001, help: 'learning rate'}        batch_size: {type: int, default: 8}        model_name: {type: str, default: 'Unet', help: 'Unet, PSPNet, Linknet, FPN'}        backbone_name: {type: str, default: 'resnet18', help: 'exampe resnet18, resnet50, mobilenetv2 ...'}        tracking_uri: {type: str, help: 'the server address'}        experiment_name: {type: str, default: 'My_experiment', help: 'remote and local experiment name'}    command: "python mlflow_training.py \            --epochs={epochs}            --categories={categories}            --lr={lr}            --tracking_uri={tracking_uri}            --model_name={model_name}            --backbone_name={backbone_name}            --batch_size={batch_size}            --experiment_name={experiment_name}"

MLflow Project имеет несколько свойств:


  • Name имя вашего проекта;
  • Environment в моем случае conda_env указывает на то, что для запуска используется Anaconda и описание зависимостей находится в файле conda.yaml;
  • Entry Points указывает какие файлы и с какими параметрами мы можем запустить (все параметры при запуске обучения автоматически логируются)

conda.yaml


name: flow_segmentationchannels:  - defaults  - anacondadependencies:  - python==3.7  - pip:    - mlflow==1.8.0    - pysftp==0.2.9    - Cython==0.29.19    - numpy==1.18.4    - pycocotools==2.0.0    - requests==2.23.0    - matplotlib==3.2.1    - segmentation-models==1.0.1    - Keras==2.3.1    - imgaug==0.4.0    - tqdm==4.46.0    - tensorflow-gpu==1.14.0

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


4. Запускаем обучение


Клонируем проект и переходим в директорию проекта:


git clone https://github.com/simbakot/mlflow_example.gitcd mlflow_example/

Для запуска вам необходимо установить библиотеки


pip install mlflowpip install pysftp

Т.к. в примере я использую conda_env на вашем компьютере должна быть установлена Anaconda (но и это можно обойти установив все необходимые пакеты самостоятельно и поигравшись с параметрами запуска).


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


$ mlflow run -P epochs=10 -P categories=cat,dog -P tracking_uri=http://server_host:server_port .

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


5. Оцениваем результаты обучения


После окончания обучения мы можем перейти в браузере по адресу нашего сервера http://server_host:server_port



Здесь мы видим список всех экспериментов (слева вверху), а также информацию по запускам (посередине). Мы можем посмотреть более подробную информацию (параметры, метрики, артефакты и какую-то доп. информацию) по каждому запуску.



По каждой метрике мы можем наблюдать историю изменения



Т.е. на данный момент мы можем анализировать результаты в "ручном" режиме, также вы можете настроить и автоматическую валидацию при помощи MLflow API.


6. Регистрируем модель


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



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



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



У нас также имеется удобный доступ ко всем моделям



и их версиям



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


7. Деплоим модель


На данном этапе у нас уже есть натренированная (keras) модель. Пример, как можно её использовать:


class SegmentationModel:    def __init__(self, tracking_uri, model_name):        self.registry = RemoteRegistry(tracking_uri=tracking_uri)        self.model_name = model_name        self.model = self.build_model(model_name)    def get_latest_model(self, model_name):        registered_models = self.registry.get_registered_model(model_name)        last_model = self.registry.get_last_model(registered_models)        local_path = self.registry.download_artifact(last_model.run_id, 'model', './')        return local_path    def build_model(self, model_name):        local_path = self.get_latest_model(model_name)        return mlflow.keras.load_model(local_path)    def predict(self, image):        image = self.preprocess(image)        result = self.model.predict(image)        return self.postprocess(result)    def preprocess(self, image):        image = cv2.resize(image, (256, 256))        image = image / 255.        image = np.expand_dims(image, 0)        return image    def postprocess(self, result):        return result

Здесь self.registry это опять небольшая обвязка над mlflow.tracking.MlflowClient, для удобства. Суть в том, что я обращаюсь к удаленному серверу и ищу там модель с указанным именем, причем, самую последнюю production версию. Далее скачиваю артефакт локально в папку ./model и собираю модель из этой директории mlflow.keras.load_model(local_path). Всё теперь мы можем использовать нашу модель. CV (ML) разработчики могут спокойно заниматься улучшением модели и публиковать новые версии.


В заключение


Я представил систему которая позволяет:


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

Данный пример является игрушечным и служит точкой старта для выстраивания вашей собственной системы, которая, возможно, будет включать в себя автоматизацию оценки результатов и регистрации моделей (п.5 и п.6 соответственно) или вы добавите версионирование датасетов, или может ещё что-то? Я пытался донести мысль, что вам нужен MLOps в целом, MLflow лишь средство достижения цели.


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


P.S. Оставлю пару ссылок:
github проект https://github.com/simbakot/mlflow_example
MLflow https://mlflow.org/
Моя рабочая почта, для вопросов ikryakin@croc.ru


У нас в компании периодически проводятся различные мероприятия для ИТ-специалистов, например: 8-го июля в 19:00 по МСК будет проходить митап по CV в онлайн-формате, если интересно, то можете принять участие, регистрация здесь .

Подробнее..

Перевод Разработка безопасных алгоритмов Проектирование

06.07.2020 18:16:50 | Автор: admin
Представьте себе водопад. Мощный. Безупречный. Всегда движется вперед по направлению к неминуемому спуску. Движимый одной из нескольких фундаментальных сил во вселенной.

Водопады потрясают по самой своей сути, так что неудивительно, что инженеры немного одержимы ими. Старый стандарт DOD-STD-2167A рекомендовал использовать водопадную модель, а мое устаревшее инженерное образование основывалось на модели Phase-Gate, которая, по моему мнению, чертовски похожа на водопадную. С другой стороны, те из нас, кто изучал информатику в университете, наверное, знают, что водопадная модель в некоторой мере является анти-паттерном. Наши друзья в академической башне из слоновой кости говорят нам, что нет-нет, Agile это путь, к успеху и похоже, индустрия доказала истинность этого утверждения.

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

Как обычно в жизни, ответ находится где-то посередине.

Гибридная, спиральная и V-образная модели


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

Звучит неплохо, но насколько это действительно эффективно?

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

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

Практическое применение

Говоря более конкретно, мы с рабочей группой NDT в Autoware.Auto, закончили наш первый спуск по левому каскаду V-образной модели (то есть совершили первую итерацию через этап проектирования) в рамках подготовки к Autoware Hackathon в Лондоне (его проводит Parkopedia!). Наш первый проход через этап проектирования состоял из следующих этапов:

  1. Обзор литературы
  2. Обзор существующих реализаций
  3. Проектирование компонентов высокого уровня, вариантов использования и требований
  4. Анализ неисправностей
  5. Определение метрик
  6. Архитектура и дизайн API


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

Обзор литературы и существующих реализаций


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

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

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

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

Из нашего обзора литературы по NDT, мы собрали следующие полезные фрагменты информации:

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


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

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

Варианты использования, требования и механизмы


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

  1. Какие варианты использования вы пытаетесь решить?
  2. Каковы требования (или ограничения) к решению для удовлетворения вышеуказанных случаев использования?
  3. Какие механизмы удовлетворяют вышеуказанным требованиям?


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

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

Варианты использования


Мне нравятся три мысленных подхода к вариантам использования (внимание, я не специалист по функциональной безопасности):

  1. Что вообще должен делать компонент? (помните о SOTIF!)
  2. Каковы способы, которыми я могу ввести входные данные в компонент? (входные варианты использования, мне нравится называть их восходящими)
  3. Каковы способы, которыми я могу получать выходные данные? (выходные или нисходящие варианты использования)
  4. Бонусный вопрос: В каких цельных архитектурах систем может находиться этот компонент?


Собрав всё вместе, мы придумали следующее:

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


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

Требования


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

В конце концов, общие требования к системе локализации не так уж и страшны:

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


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

Механизмы


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

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

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

image

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

Анализ неисправностей


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

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

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

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

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

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

Всего мы выработали 15 рекомендаций. Я бы рекомендовал вам ознакомиться с ними.

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

Определение метрик


То, что измеряется поддается управлению
Популярная фраза менеджеров


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

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

Для нашей реализации NDT мы разбили метрики на четыре широкие группы:

  1. Общие метрики качества программного обеспечения
  2. Общие метрики качества встроенного программного обеспечения
  3. Общие метрики алгоритма
  4. Специфические для локализации метрики


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

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

Архитектура и API


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

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

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

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

  1. Написать классы и публичные методы для алгоритма (создать архитектуру)
  2. Написать тесты для алгоритма с использованием публичного API (они должны проваливаться!).
  3. Реализовать логику алгоритма


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

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

Каковы же тогда степени свободы в NDT?

Обзор литературы говорит нам о том, что существуют различные способы представления сканирования и наблюдения (например, P2D-NDT и D2D-NDT). Аналогичным образом, наш инженерный документ высокого уровня говорит о том, что у нас имеется несколько способов представления карты (статический и динамический), так что это тоже степень свободы. В более свежей литературе также говорится о том, что задача оптимизации может быть пересмотрена. Тем не менее, сравнивая практическую реализацию и литературу, мы видим, что даже детали решения для оптимизации могут отличаться.

И список можно продолжать и продолжать.

По итогам первичного проектировании мы остановились на следующих концепциях:

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


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

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

Далее


После проектирования, конечно, приходит время реализации. Официальная работа по внедрению NDT в Autoware.Auto была проведена на хакатоне Autoware, организованном Parkopedia.

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

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

Подписывайтесь на каналы:
@TeslaHackers сообщество российских Tesla-хакеров, прокат и обучение дрифту на Tesla
@AutomotiveRu новости автоиндустрии, железо и психология вождения




image

О компании ИТЭЛМА
Мы большая компания-разработчик automotive компонентов. В компании трудится около 2500 сотрудников, в том числе 650 инженеров.

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

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

Читать еще полезные статьи:

Подробнее..

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

26.06.2020 14:09:33 | Автор: admin
От автора

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

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

Итак


image
Бизнес есть Бизнес, Разработка есть Разработка, и не встретиться им никогда, пока

Видел статью о том, как подружить кошку с собакой. Лайфхак от мамкиных бихевиористов:

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

Решение годное для нишевого interspecies threesome, наверное. Попробовал чуть не лишился глаза и кошки.

Примерно такие же потери и чувства у меня вызывает вопрос знакомства бизнеса и разработки.

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

Сложности перевода


Часто у разработчика нет даже поверхностного понимания вашего бизнеса или бизнеса клиента. И тогда у него включается инструкция:

Шаг 1. Прийти и потребовать переписать все на RUST.

Шаг 2. Выгореть, так как вы не будете давать переписать все на RUST.

if (переписать_все_на_RUST == false) then разработчик.выгореть({immediately: true})

Так почему же разработчик не хочет понимать ваш бизнес?

В поисках смысла и цели


Цель у любого бизнеса одна принести пользу другим людям. За эту цель платят фиатными деньгами и социальным капиталом.

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

Поэтому ему сложно оценить свой вклад он видит только код и деньги за этот код.

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

Поясним


Обычно в фирмах есть разные отделы: маркетинг, тех-поддержка, аналитика, продажи, стратегия. А вдалеке от всех, существует полу-автономная резервация под названием отдел разработки, с которыми общаются через специального дипломата-переводчика (PM, Team Lead).

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

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

Рекомендация


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

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

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

Как этого добиться


У меня это получилось так:

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


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

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

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

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

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

Вместо вывода


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

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

Почему я провожу асинхронные собеседования (в чате)

01.07.2020 12:12:44 | Автор: admin
Конечно, не все, только первые собеседования и только с программистами (в свой стартап). С теми, кто прошел интервью в чате успешно, обязательно устраиваю живой разговор. Но первое интервью в чате это оказался такой простой и полезный лайфхак, что грех не рассказать подробно.

Асинхронные собеседования в чате

Немного контекста. У меня два проекта: Kotlin в компании JetBrains и наш с Олей Китаиной стартап Alter. Оба требуют внимания, времени реально не хватает. Чтобы времени стало больше, надо найти в Alter лид-девелопера, чтобы постепенно передать ему/ей команду и всю разработку. Но времени-то уже нет :) Так что собеседования были серьезной проблемой, пока я пытался проводить их как делал всегда раньше созваниваясь по видео, то есть синхронно. Со временем была главная сложность, но она, конечно, не единственная при синхронном собеседовании.

Проблемы синхронных собеседований


Важно понимать, что я не против проведения собеседований вживую или по видео. Я просто хочу рассказать о том, какие с этим есть проблемы:
  1. Я должен выделить 30-45-60 минут времени заранее.
  2. Собеседование приходится откладывать до той даты, когда у нас обоих совпадет свободное время.
  3. Все время собеседования я должен следить за мыслью кандидата, но надо прерываться, пока кандидат думает.
  4. Если на пятой минуте становится понятно, что кандидат не подходит, неудобно так вот резко заканчивать разговор (особенно, если кандидат потратил время, чтобы приехать в офис).
  5. Кандидаты, как правило, нервничают, и надо делать какие-то поправки в духе ну, это он сказал, потому что волновался или ну, ей просто неудобно было долго молчать, раздумывая, вот она и сказала то, что быстрее придумала.
  6. Кандидат сильно ограничен по времени решения задачи, потому что нам надо все успеть за 30-45-60 минут.

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

Не надо выделять время заранее


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

Не надо откладывать собеседование


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

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


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

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

Нет проблемы закончить быстро


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

Кандидаты меньше нервничают


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

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

Кандидату не надо торопиться


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

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

Недостатки интервью в чате


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

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

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

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

Заключение


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

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

Анатомия юнит тестирования

21.06.2020 20:19:44 | Автор: admin
Юнит тесты обязательная часть моих проектов. Это база, к которой добавляются другие виды тестов. В статье Тестирование и экономика проекта, я изложил доводы почему тестирование выгодно для экономики проекта и показал, что юнит тестирование лидирует с экономической точки зрения. В комментариях было высказано мнение, что тестирование требует больших усилий, и даже юнит тестирование не приемлемо из-за этого. Одной из причин этого является неопытность команды в тестирование. Чтобы написать первую тысячу тестов команда тратить много времени, пробуя и анализируя различные подходы.

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


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

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

О наследование


Постарайтесь не применять наследование. Вместо него используйте композицию зависимостей. Часто наследование применяют для реализации принципа DRY (dont repeat yourself) вынося общий код в родителя, но тем самым нарушая принцип KISS (keep it simple stupid) увеличивая сложность юнитов.

AAA (Arrange, Act, Assert) паттерн.


Если посмотреть на юнит тест, то для большинства можно четко выделить 3 части кода:
Arrange (настройка) в этом блоке кода мы настраиваем тестовое окружение тестируемого юнита;
Act выполнение или вызов тестируемого сценария;
Assert проверка, что тестируемый вызов ведет себя определенным образом.
Этот паттерн улучшает структуру кода и его читабельность, однако начинать писать тест нужно всегда с элемента Act.

Driven approach.


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

Суть в том, что код который вы пишите должен иметь причину своего существования. Важно, что бы причина была существующей, а не предполагаемой, и эта причина должна иметь в конечном итоге связь с бизнес историей.
С чего мы начинаем разработку конкретного функционала? с требований бизнеса, которые типично выглядят так: Пользователь с любой ролью должен иметь возможность создать запись, таким образом он выполнить такую то бизнес операцию.
Используя driven approach первое что мы должны сделать
  • Это создать место в UI слое, где пользователь может создать запись, скажем страницу в приложении, на которой будет кнопка Создать запись. Почему мы это сделали? потому что это требует бизнес история.
  • Кнопка Создать запись будет требовать реализации обработчика click события.
  • Обработчик события будет требовать реализации создания записи в терминах слоя бизнес логики.
  • В случае клиент-серверной архитектуры, клиент будет обращаться к некоторому end point на стороне сервера для создания этой записи.
  • Сервер в свою очередь может работать с базой данных, где такая запись должна быть создана в отдельной таблице.


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

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

AAS (Act, Assert, Setup) паттерн.



AAS этот тот же AAA паттерн, но с измененным порядком частей, отсортированных с учетом Driven approach и переименованной Arrange частью в Setup, чтобы отличать их по названию.

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

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

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

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

Принципы SOLID.



Из принципа SOLID, с точки зрения юнит тестирования очень важны 2 принципа:

Single responsibility principle позволяет снизить количество тест кейсов для юнита. В среднем на юнит должно приходиться от 1 до 9 тест кейсов. Это очень хороший индикатор качества юнита если тест кейсов больше или хочется их сгруппировать, то вам точно нужно разделить его на два и больше независимых юнитов.

Dependency inversion principle позволяет легко создавать и управлять сложнейшими окружениями для тестирования через IoC контейнеры. В соответствии с данным принципом, юнит должен зависеть от абстракций, что позволяет передавать ему любые реализации его зависимостей. В том числе, и не продакшен реализации, созданные специально для его тестирования. Эти реализации не имеет в себе никакой бизнес логики и созданы не только под конкретный тестируемый юнит, но и под конкретный сценарий его тестирования. Обычно они создаются с помощь одной из библиотек для mock объектов, такой как moq.

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

Качество кода


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

Однотипность тестирования


Много приложения реализовано в распределенной и модульной архитектуре, где разные части написаны на различных языках, скажем клиент-серверные приложения, где клиент написан под веб на typescript и сервер написанный на c#. Важной целью для таких проектов будет приведение тестов для любой части, независимо от языка к единому подходу. Это значит, что все тесты на проекте используют AAA или AAS подход. Все тесты используют mock библиотеки с похожим API. Все тесты используют IoC. И все тесты используют одинаковые метафоры. Это позволяет повысить переносимость удачных практик на разные части проекта, упростить адаптацию новых коллег (выучил раз и применяй везде).

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

Из песочницы Техническая документация в разработке ПО кто, зачем, когда и как описывает проект

19.06.2020 18:10:12 | Автор: admin
image

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

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

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

Другой пример государственные организации или организации, чья деятельность ограничивается или подчиняется законам и надзорным органам. Они обязаны осуществлять разработку ПО по всем правилам и с соблюдением всех стандартов. В таких проектах техническая документация, подготовленная по ГОСТам, необходимое условие.
И разумеется, грамотно составленная и актуальная документация необходима для того, чтобы каждый участник в процессе разработки мог обращаться к документам, если возникают вопросы по конкретной задаче или по всей системе в целом.
Техническое задание и технический проект два разных документа. Техническое задание отвечает на вопрос что нужно сделать?, его составляет аналитик в самом начале проекта. Технический проект разрабатывает технический писатель. Этот документ создается после ТЗ и отвечает на вопрос как нужно делать?.

Кто пишет техническую документацию


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

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

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

Кто такой технический писатель


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

Для этого он собирает информацию и материалы от участников проекта и документирует эти данные согласно требованиям заказчика, в том числе и в соответствии с ГОСТами. Речь идет о ГОСТ 19 Единая система программной документации и ГОСТ 34 Информационная технология. Комплекс стандартов на автоматизированные системы. Также технический писатель следит за актуальностью технической информации, если это необходимо на длительных и сложных проектах.

Какая техническая документация нужна разработчику


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

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

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

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

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

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

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

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

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

Когда составлять техническую документацию


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

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

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

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

Категории

Последние комментарии

© 2006-2020, personeltest.ru