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

Скрам

Scrum и кризис учить, лечить, мочить. Будущее за микрокомпаниямим и как влюбиться в тишину

15.06.2020 20:17:21 | Автор: admin

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


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

Я бы это назвал упорядоченный хаос. И он мне нравится. Особенно сейчас.



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


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


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


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


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


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


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


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


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


У ней особенная стать в Россию можно только верить


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



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


Олег: Как ты думаешь, мы банк или IT компания?
Я: Олег, очевидно, учитывая, как ты запускаешь бизнес взял модель Capital One, американскую модель.


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


Он говорит: Нет, мы не банк, мы IT компании, я это полностью принимаю.


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


А у нас в PropellerAds в квартире газ, бензин и квас


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


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


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


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


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


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


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


Даёшь пятилетку спринт за два дня!


У вас сейчас спринты остались недельные или сократили.


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


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


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


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


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


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


Ты помнишь, как всё начиналось? Всё было впервые и вновь.


Как вы пришли в Agile-культуре в PropellerAds?


Пришли мы к культуре эволюционно.


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


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


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


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


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


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


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


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


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


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


Нет у революции начала, нет у революции конца...


Конечно. Скажи, сколько длилась первичная Agile трансформация?


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


Все что для этого нужно сделать это сказать эге-гей, ребята, вот вам новые команды, а теперь никто никому задачу не ставит. Теперь каждый человек в команде сам берет задачу. И дать им какие-то правила, например, scrum, daily standup, проведения ретроспектив, ответственность за свой процесс, непрерывные улучшения. Выступление на demo, как главный результат работы команды, такой главный элемент отчетности, контроля. И все встречи, связанные с планированием, с подготовкой задач и так далее. Это просто.


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


Считается, что 30 процентов сотрудников не выдерживают перехода на Agile культуру, увольняются или их увольняют. Сколько по твоему мнению у вас получилось потерять?


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


Мне тоже интересно, что значит, не подошел?


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


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


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



Последний негритёнок поглядел устало, он пошёл повесился, и никого не стало.


Скажи, как тебе сейчас резкая перемена работы на удалёнку?


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


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


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


To be continued...


С чем вы столкнулись?


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


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


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


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


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


Она увеличивает амплитуду, и причем она вот эти вот пики по краям поднимает.


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


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


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


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


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


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


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


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


Выбраковка


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


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


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


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


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


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


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


Иногда нужны, чтобы захватить какую-то долю рынка, но очень часто мы, общаясь со стартапами, приходим к мнению, что они без нас прекрасно справятся. Ну и замечательно. Да, в Силиконовой Долине есть такие кейсы, но мне кажется, что это тоже не супер mainstream, что там прямо сидят исключительно стартапы, которые хотят капитализацию сделать и какой-то просто супер шикарный exit через год работы. Это вот такие истории, про которые много пишут, но это тоже далеко не все компании, инвесторы очень осторожно к своим деньгам относятся. Да, часто люди надеются на то, что они сделают за 2 года какие-нибудь там Х и дальше нули прибавляются, 10, может быть больше. Но опять же, зная много инвесторов, которые на оба рынка работают, таких историй все меньше и меньше.


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


И нет такого, что прям заносят, завозят, и все остановилось. Да, рынок замирает, но не кардинально, то есть это выглядит больше, как пауза, деньги-то никуда не исчезли у инвесторов, они остались там. Может быть у кого-то их источники дохода до какой-то степени остановились в плане привнесения и пополнения их средств, но деньги не исчезают, все в порядке, просто люди переосмысливают, как Apple любит говорить, переосмысливают в принципе, какие сейчас рынки стрельнут, что будет онлайн бизнес, какие-то еще сферы, как образование поменяется. Как говорят, образование будет The Next BIG Thing и так далее. Как Финтех поменяется под эту историю, может быть, какие-то интересные вещи стрельнут, то есть, люди внимательно смотрят, ищут следующие точки, где стрельнет, что называется, в какие области стоит вкладываться.


Весь мир насилья мы разрушим до основанья, а затем...


Ты думаешь, что мир станет еще более открытым, несмотря на закрытие границ?


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


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


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


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


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


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


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


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


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


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


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


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


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


Стаи маленьких бизнес-пираний


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


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


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


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


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


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


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


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


Сколько может длится долина смерти? По твоему опыту и вообще в принципе.



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


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


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


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


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


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


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


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


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


Здесь смысл в другом, если человек что-то сделал, и это не понравилось вышестоящему начальству, он гарантированно получит наказание. Если человек ничего не сделал, но сделал ИБД, наказания точно не будет. Как найти общий язык между командами маркетинга, бизнеса, разработки, эксплуатации на совещаниях Agile, чтобы эти встречи не делись по 10 часов и не превращались в схватки: твоя моя не понимает?


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


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



Фасилитаторы фасилититоровали, фасилитирировали и дофасилитировались


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


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


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


Магия успеха полюбить тишину


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


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



Мы провели с Мариной Алекс, вашим покорным слугой и Алексеем Куксёнком бесплатный курс "Вечерняя школа Слёрма по Аджайл" и мы увидели востребованность людей вникнуть в профессию scrum-мастера. Ощутимо, что в рамках приближающих изменений эта профессия станет крайне востребованной на IT-рынке труда. А IT это уже сейчас видно из-за гибкости и Agile-методик быстрее адаптируется и восстанавливается уже во время кризиса и находит новые возможности.


Сейчас мы запускаем курс Профессия SCRUM-мастер.


Старт 9 июля, длительность 2 месяца, 2 занятия в неделю, начало в 19:00.


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


Особенности курса:
Много общения с экспертами-практиками;
Полный обзор роли scrum-мастера;
Курс основан на опыте экспертов из сервисной и продуктовой разработки;
Отработка новых знаний вживую в безопасной обстановке курса.


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


Присоединяйтесь: https://to.slurm.io/fXCy9w

Подробнее..

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

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

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

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

image

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

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


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

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

image

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

image

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

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

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

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

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

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

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

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

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

image

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

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

image

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

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

Процесс


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

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

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

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

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

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

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


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

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

Как скрам помогает стать более сильным разработчиком?

28.11.2020 00:23:46 | Автор: admin

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

 Copyright Max Degtyarev (http://personeltest.ru/aways/www.behance.net/maxdwork) Copyright Max Degtyarev (http://personeltest.ru/aways/www.behance.net/maxdwork)

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

Что до Soft skills, то, к сожалению, это считается чуть ли не лишним ингредиентом, пустой тратой времени, или же несущественным элементом. Ценность Hard Skills сильно выше, чтобы переставать работать с человеком из-за проблем с Soft Skills.

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

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

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

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

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

Цель

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

Однако, здесь не достаёт чуточку цели.

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

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

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

Итерации

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

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

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

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

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

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

Работая в стартапах сложно сказать какую проблему придётся решать через 6 месяцев. Никто не знал, что видео-сервис для свиданий станет самым популярным в мире видео-стриминговым сервисом YouTube. Так же, как никто не предполагал, что игра для социализации может превратиться в чат для коллег, как в случае Slack. Бизнесы, которые не смогли повернуть свои продукты в правильном направлении, либо уже исчезли, либо близки к провалу.

Пример плохого развития событий в фазовом подходе Waterfall.Пример плохого развития событий в фазовом подходе Waterfall.

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

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

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

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

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

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

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

Гибкая архитектура

Есть одна фундаментальная вещь, которую нужно понять с точки зрения разработки: преждевременное принятие решений (up-front design)это не всегда хорошо, а чаще плохо.

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

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

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

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

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

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

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

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

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

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

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

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

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

When requirements change, the difficulty in making such a change should be proportional to the scope of the change, not to the shape of the change. The difference between scope and shape often drives the growth in software development costs. It is the reason that the first year of development is much cheaper than the second, and the second year is much less expensive than the third.

The goal of software architecture is to minimize the human resources required to build and maintain the required system.

Robert C. Martin, Clean Architecture: A Craftsmans Guide to Software Structure andDesignRobert C. Martin, Clean Architecture: A Craftsmans Guide to Software Structure andDesign Роберт Мартин, Чистая Архитектура: искусство разработки программного обеспечения. Роберт Мартин, Чистая Архитектура: искусство разработки программного обеспечения.

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

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

  • Меньше нового кода, означает меньше поддержки.

  • Меньше нового кода также означает меньше всего что может сломаться (работает, не трогай! помните?).

  • Меньше нового кодаменьше когнитивной нагрузки.

  • Меньше нового кодабольше уверенности в результате работы.

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

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

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

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


Если говорить о коде, то программисты нанимаются для того, чтобы вносить изменения в поведение программного обеспечения так быстро, насколько это возможно. Разработчики могут поддерживать скорость изменений на достаточном уровне только создавая достаточно гибкую архитектуру. Для этого требуется своевременная коммуникация с бизнесом для выяснения что на самом деле ему надо. Также, требуется тщательно продумывать каждое изменение, контролируя архитектуру и технический долг, и постоянно уточняя требования. Если не обратить внимание хотя бы на одну из этих составляющих (перестать коммуницировать с бизнесом или же не обращать внимание на архитектуру), то так или иначе, но скорость внесения изменений очень быстро упадёт, и к вам возникнут вопросы. В последнее время всё чаще встречаются термины Agile Architecture и Lean Architecture. Я предпочитаю объединить эти понятия в одном термине: Гибкая архитектура.

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

Сильный разработчик

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

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

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

Представьте, насколько сильно изменилась архитектура Android, который изначально был задуман как операционная система для камер, и только. А теперь это одна из двух самых популярных мобильных платформ. Другой пример, PayPal, который создавался как сервис перевода денег между телефонов с операционной системой Palm OS. А теперь сервис обрабатывает миллионы платежей по всему миру.
Врядли, развитие кодовой базы этих проектов было монотонным ростом функционала из года в год. Уверен, что такие изменения, словно большой взрыв, порождают массу работ по адаптации, рефакторингу и переписыванию с ноля. Это конечно одни из самых сложных случаев. Но кто может заранее предположить путь вашего проекта?

А где жескрам?

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

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


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

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


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

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


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

Вывод

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

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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru