Comments 8
В книге «Посткапиталистическое общество» Питер ДрДрукер
Сначала прочитал как "постапокалипсическое общество" - уж больно похожа на него реальность иногда)
Очень много проработав в корпоративной разработке софта, могу сказать, что это редкость, если на (само)обучение выделяется часть рабочего времени
Сначала прочитал как "постапокалипсическое общество" - уж больно похожа на него реальность иногда)
))) +1
Очень много проработав в корпоративной разработке софта, могу сказать, что это редкость, если на (само)обучение выделяется часть рабочего времени
За тем и пишу подобные статьи, чтобы рано или поздно это изменилось. - подливаю масла в огонь. Если все говорят что так правильно, то те кто делает по другому начинают хотя бы подвергать сомнению "статус кво". - вода камень точит.
Например, мы выпускаем новый релиз нашего продукта каждый год или квартал, а компании лидеры делают это несколько раз в день.Вот, не очень хороший пример. Плохой. На носу я вертел продукты, которые релизятся несколько раз в день. Давайте раз в год, но чтоб как штык! Как у молодого! Чтоб делало свое дело и не падало, надежно и оттестировано, а не с новыми иконпаками, озвучкой, закругленными углами табов, улучшенной формой регистрации, двухфакторной авторизацией и трехфакторной аутентификацией, и все это для калькулятора, который до сих пор не может одновременно и хекс-вид и синус без переключения между режимами инж/прогр.
Давайте предположим что продукт делает 500+ человек. За этот год в одном ежегодном релизе они выдадут продукт с тучей функциональности, потом весь следующий год будут собирать обратную связь от пользователей и исправлять то что попало мимо ожиданий, а весь следующий год мы, как пользователи, будем мучиться и страдать в 35 местах. При этом в худшем случае, через год можно найти, что в половине мест всё равно сделали не так и будем ждать ещё год до следующего релиза, когда сделают так как надо.
Быстрые релизы нужны для того, чтобы фокусироваться и поставлять то что нужно пользователю сейчас, также быстро собирать обратную связь и не заставлять нас, пользователей, страдать от неудачных решений (реализации).
То что вы описаете похоже на то, когда есть компонентные команды (продукт поделён на части и каждая команда отвечает за свою часть), и видно что приходит релиз с кучей минорных обновлений, когда самое главное так и не работает. Чаще всего эти команды ждут команду "бутылочное горлышко", когда у неё будет возможность сделать что-то важное, а сами делают и поставляют то что могут сейчас (минорную функциональность). = это история моего последнего места работы когда продукт делают 30+ команд (500+ человек)
Но мои контраргументы:
1) Туча чаще всего не нужна. Чтоб прям совсем туча и уже не на старте. Да в не таком уж и маленьком офисе (MS, OO — не важно) за год изменений не туча, из них больше половины чисто визуальные.
2) По опыту то, что релизится изо всех сил почаще, на поверку не оказывается реально лучше аналога, который сильно не торопится. Прямо во столько раз лучше, во сколько раз чаще.
3) Новый релиз — новые баги. Что далеко ходить — программка для покупки билетов на электричку от РЖД — каждый новый релиз добавляет новые проблемы, но не каждый убирает старые. Так вот, не хотелось бы почаще… И вообще, я, как юзер, не хочу обновляться несколько раз в день. Особенно если обновлять надо много чего, и все оно обновляется по секундомеру, а не календарю. «Ну, так и не обновляйся»? Но сидеть на устаревшей версии тоже не хочется, тем более, зачем-то же ее выкатили, может, безопасность, может, совместимость, куда деваться…
4) как говорится, last but not least — гонка с конкурентами за скорость релизов перерастает в скорость релизов как самоцель. Вплоть до тупой перекомпиляции для изменения номера билда, до добавления абсолютно не нужных «фич». А потом анекдоты ходят, типа: кто быстрее перерастет в операционную систему — резалка дисков или смотрелка графики?
Максим Евстратов Ок, статья хороша и с посылом я согласен. Но. Не раскрыто самое главное противоречие: на рынке в условиях конкуренции выделять ресурсы на обучение и эксперименты довольно дорого. Если у вас 30% фонда рабочего времени времени уходит на развитие сотрудника, а у соседней компании — нет, то кто окажется выбывшим в этой гонке?
Ок, но кажется, что в долгосрочном периоде вам это выгоднее все-таки вкладываться в развитие.... Однако любой долгосрочный период это сумма краткосрочных. Если в соседней компании сразу нанимают людей с нужными навыками, то они приносят ей уже 100% отдачу. А через 3-4 лет, когда их навыки устаревают, их можно заменить, купив с рынка новых, с актуальными навыками.
Есть и третий вариант — наибольшее конкурентное преимущество получат компании, в которых люди будут этим в свободное время заниматься, то есть требующие (хочешь работать - учить постоянно!), но не освобождающие для этого время работника.
Вот и получается, что вопрос в том, как любой компании, которая хочет и развиваться, и сохранять конкурентные позиции, и о сотрудниках заботиться, создать такую систему обучения, которая позволит достичь всех трех целей... Особенно если она не является сверхмаржинальным бизнесом и живет не на деньги инвесторов.
Максим Евстратов
Evgenii Parfenov попробую с ответом зайти чуть с другой стороны, через байку из жизни.
У меня в команде было два инженера по тестированию, которые не умели писать автотесты. Те немногие автотесты что были в команде, были написаны разработчиками. Всё тестирование как нового функционала, так и старого осуществлялось вручную.
Что сделали: взяли на время в команду двух стажёров-джуниоров и эксперта по автоматизированному тестированию, научили джуниоров ручному тестированию, двух инженеров отправили учиться автоматизированному тестированию.
После возвращения с обучения они начали активно "погашать долг" по покрытию функционала автотестами. Спустя два года с момента начала затеи все автотесты пишутся в том же спринте в котором разрабатывается новый функционал. Тестирование теперь в 9 из 10 случаев осуществляется с помощью автотестов.
Результаты:
- Утечка багов из команды на более позднии стадии интеграции сократилась в 4 раза. С 28 багов в Программном Инкременте №9 до 7 в Инкременте №14. Больше нет утекающих "блокеров", которые блокируют интеграцию всего продукта пока команда не поставит фикс.
- Время интеграции результатов команды в продукт сократилось с 10 дней, до 1-2 дней в конце спринта. Интеграция начинается сразу же в ходе спринта по готовности фичи.
Если у вас 30% фонда рабочего времени уходит на развитие сотрудника, а у соседней компании — нет, то кто окажется выбывшим в этой гонке?
У меня в продукте также был поезд, который не вкладывался в качество, и итог такой что после 2-х лет этот поезд сейчас слабое звено всей "фабрики" и не позволяет всему продукту ускорится. Потому что Владелец Продукта поезда делал выбор в пользу бизнес-фичей. Сейчас он грозится выделить отдельный инкремент на то, чтобы ликвидировать долг, который создан в его поезде. Но пока у него не особо получается, на него давят акционеры с бизнес планами. Он скорее загнал себя и свой поезд в темный угол.
Слабое звено он по той причине, что за эти 2 года было сделана туча функциональности и продукт стал ещё более сложным и при этом обрёл качество "хай-лоад". И поэтому ситуация для этого поезда стала ещё более драматичной. Для них теперь каждый инкремент - это геройский подвиг. Требуется очень много усилий, чтобы всё работало. При этом соседние поезда сидят и "жмут кнопки" (автоматизация) и недоумевают почему рябятам требуется от 2-х до 4-х недель чтобы выдать стабильный инкремент.
Поэтому если у соседней компании нет этих вложений, молодцами они кажутся только здесь и сейчас.
Если в соседней компании сразу нанимают людей с нужными навыками, то они приносят ей уже 100% отдачу. А через 3-4 лет, когда их навыки устаревают, их можно заменить, купив с рынка новых, с актуальными навыками.
Мой опыт показывает, что люди с нужными навыками не очень стремятся устраиваться на работу в компании где "жопа". Для них эти компании не "секси". То есть им предлагают сделать то, что не делалось последние 4 года и сделать это быстро, потому что дальше уже невозможно (клиенты ругаются \ уходят). При этом в этой работе для них нет ничего нового, они вложат 1,5-2 года в это и при этом ничего новому для себя не научаться.
Людей с нужными навыками немного и за них есть конкуренция. Поэтому они чаще выберут компанию, которая уже движется в правильном направлении. Исключения, про которые я знаю, завязаны на очень много денег и как правило это приход в компанию для отсиживания года, получения годового бонуса размером в годовую зарплату, и "сваливания" в благополучную компанию где интересно работать.
Есть и третий вариант — наибольшее конкурентное преимущество получат компании, в которых люди будут этим в свободное время заниматься, то есть требующие (хочешь работать - учить постоянно!), но не освобождающие для этого время работника.
Это ведёт к выгоранию так как нарушен баланс "работа - личная жизнь". Это может сработать в отдельных случаях - на короткий промежуток времени, как геройский подвиг, но это не может быть системным решением.
Особенно если она не является сверхмаржинальным бизнесом и живет не на деньги инвесторов
Сверхмаржинальность здесь появляется за счёт способности делать правильный продукт правильно = быстро. Мы быстро делаем фичу и отдаём её пользователям, также быстро собираем обратную связь и корректируем фичу под ожидания\реальность.
То есть развитие (обучение) ведётся по двум направлениям:
"technical excellence" - цель которого сократит T2M и косты на быструю поставку.
"Market fit" (или fit for purpose) - с целью максимизировать создаваемую ценность для бизнеса и клиентов (отдачу) на те ресурсы что у нас есть.
Вот и получается, что вопрос в том, как любой компании, которая хочет и развиваться, и сохранять конкурентные позиции, и о сотрудниках заботиться, создать такую систему обучения, которая позволит достичь всех трех целей...
Моя точка зрения - чтобы продукт \ бизнес был успешн должна сходиться его экономика, но в эту экономику должна быть заложена эта система обучение (те самые 30% на обучение).
Если это есть, то ответ на вопрос "как" можно будет нащупать эмпирически.
Из собственной практики в высокотехнологичной кампании - управление изменениями, фаселитаторы - все применяется в соответствие веяниям времени. Однако решающим остается наличие компетентных разработчиков способных как освоить так и создать новые технологии. Такие люди или группы обычно формируются за довольно продолжительное время - лет 30-ть, и в среде которая этому способствует. Причем среда это не обязательно инкубатор, а часто арена соревнований. Касательно параллельной разработки, или применения, новых технологий и собственно продукта. Если концепция и оценка технической реализации продукта включает новую технологию которую разработчики рекомендуют (уверены в какой-то степени что заработает) тогда это работает с определенной долей риска. Если разработчики не уверены, но хотят попробовать со словами что через пять лет это будет нужно - открывается технологический проект.
Отличная статься, спасибо. Добавить нечего, кроме того, что ни разу не работал в компании, где выстроена система обучения и роста сотрудников или она работала на приоритетных проектах. Естественно, в большинстве случаев на таких проектах управление смотрит в первую очередь на запуск релиза, а не на профессиональный рост сотрудников. Однако, мне приходилось такую атмосферу создавать на проекте самостоятельно, и это безусловно давало своим плоды, особенно на молодых звёздых, которые очень быстро выстреливали и начинали приносить огромную пользу проекту!
Обучение должно быть неотъемлемой частью ежедневной работы