Встреча совсем скоро

Я буду выступать на Третьем Аналитическом марафоне 17 декабря с докладом «Польза и вред от технического долга в аналитике». Несмотря на плотный график и яростные попытки вирусов подорвать приготовления, все сделано, и встреча состоится послезавтра.

Я подниму тему, с которой все сталкивались не единожды, и которая не раз приводила в уныние не одну команду разработки. Все мы сталкивались с ситуацией, когда надо срочно ускоряться, разрабатывать спецификации, писать код, выпускать релизы. Начальство говорит: «Давай, давай»! Но сделать ничего быстро не получается. Груз накопившихся в разработке проблем давит на плечи. И мы занимаемся переделкой ранее сделанной работы. Нас настиг Техдолг 💣

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

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

@aheadofthepack

Ощущения не менее важны функциональности

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

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

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

@aheadofthepack

Писать в стол не модно

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

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

И что в итоге? Заигравшись в этом интересном процессе, я начал утрачивает интерес к своему произведению. А потом и вовсе кинул статью "в стол" никуда в итоге не опубликовав.

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

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

@aheadofthepack

Меняющиеся походы самообучения

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

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

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

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

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

Даже не смотря на малую выборку, этот тренд был заметен и у нас в фирме. По сравнению с 2019, в 2020 году читать стали меньше. При этом значительно меньше стали дочитывать книги до конца. Из-за чего это происходит писал в прошлом году в посте Два подхода к чтению книг. Однако не все так печально. Айтишники начали больше времени тратить на участие в легких формах обучения: семинарах, конференциях, митапах. Теперь понятно куда уходило время, и что делать EdTech-компаниям и предпринимателям. ;-) Хотя я считаю, что такие формы обучения прогрессивны, но недостаточны. Их крайне желательно подкреплять чем-то еще из классической тяжелой артиллерии.

@aheadofthepack

Обещать - не значит жениться!

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

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

Давайте посмотрим откуда берется такое непонимание и разница в расчетах?

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

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

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

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

@aheadofthepack

Бег за Лидером

Вы смотрели соревнование по легкой атлетике по бегу на средние дистанции?

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

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

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

@aheadofthepack

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

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

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

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

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

Еще одно интересное определение - Минимальный привлекательный продукт (Minimum Loveable Product, MLP). Концепцию придумал Кэт Нуун, введя понятие продукта, который будет не только решать проблемы пользователей, но и устанавливать с ними эмоциональную связь. В предложенной концепции на передовую выходят не просто важные функции, или те, за которые пользователь готов заплатить, а опыт пользования. Это может быть дизайн, эстетика, удобство использования, например скорость работы или плавность изменения экранов. Пользователь уже имеет опыт с похожими альтернативами и минимальной функциональностью его уже так просто не зацепить. MLP позволят дифференцировать продукт на уже занятом рынке.

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

@aheadofthepack

Минимальные продукты (продолжение)

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

📚 Марти Каган «Вдохновленные»
📚 Скотт Хёрф «Как создать продукт, который полюбят»
📚 Роман Пихлер «Управление продуктом в Scrum»
📚 Марка Денна и Джейн Клиленд-Хуан «Software by Numbers»
📚 Эрик Рис «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели»

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

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

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

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

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

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

Режим «автопилот» работать не будет если:
✔️ Необходимо виртуозно разрулить проект в нестандартных условиях с ограниченным лимитом времени-денег-ресурсов
✔️ Меняется технологический стек
✔️ На порядок увеличивается масштаб чего-либо
✔️ Если суммарные риски начинают превышать выработанные контролируемые значения
✔️и т д.

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

@aheadofthepack

Политика Открытых ушей

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

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

👉 Подробнее в статье на vc

Системный подход vs нафигачить

Большинство IT-компаний начинают с малого. Часто с хаотического процесса, держащегося на здравом смысле и воле основателей. Если компания перерастает период «младенческой смертности», начинается осознание не только что нужно делать, но и как нужно делать. В процессе эволюционного развития R&D начинают вводить сложные процессы. При таком подходе становится возможным создавать серийное, масштабное и долгоиграющее; обрести устойчивость и повторяемость результатов разработки продукта или услуги. Происходит постепенное обрастание детальным BA/SA, сложным процессом CI/CD, полным QA automation и т д. Разработка становится неповоротливой, наподобие перекаченного атлета.

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

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

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

@aheadofthepack

Насильственное обучение

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

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

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

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

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

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

@aheadofthepack

Делать как для себя

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

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

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

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

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

Эти примеры всего лишь из внутренних процессов. Когда что-то уходит за пределы команды вариации возрастают.

Думаю, всегда стоит подумать:
⚽️ Кто стоит следующий в цепочке действий?
🏀 Хватает ли ему знаний о том, что было сделано?
🏐 Как облегчить ему работу?
🏉 Как бы я хотел, чтобы мне передали задачу?

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

@aheadofthepack

Полезный и вредный технический долг ч.1

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

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

🎯 Экономия ресурсов. Прежде всего - капитала. Молодой фирме крайне желательно как можно быстрее проверить продуктовые гипотезы. Как можно быстрее вывести минимально жизнеспособный продукт MVP на рынок и запустить новый цикл разработки. При этом минимизировать первоначальные затраты. Физических ресурсов, ни тем более денежных у фирмы может и не быть. Основатели стартапа, вынуждены экономить ресурсы. Почему? Все просто - вероятность успеха, особенно в новой области невысока. Поэтому взятие техдолга – это большая экономия стартапов на старте. Лучше за меньшие деньги отработать как можно больше гипотез.

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

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

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

@aheadofthepack

Полезный и вредный технический долг ч.2

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

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

Чтобы реализовать MVP необходим минимум технической и тестовой документации и полезных процессов. Для Proof of concept (PoC) технического долга можно набрать еще больше. Важно лишь зафиксировать что конкретно хотим проверить (наши гипотезы) и какими методами, чтобы потом не создавалось искажений при интерпретации результатов. Думаю, многие согласятся с Agile подходами. Работающий прототип и быстрая проверка результата более важна чем наличие правильной полной документации и отлаженного процесса. Работающее MVP является ценностью для пользователей, PoC для команды разработки или инвестора. При этом использование долга происходит наиболее эффективным образом. Об этом я уже писал недавно в посте Системный подход vs нафигачить

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

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

@aheadofthepack

Бесконечный потолок

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

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

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

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

@aheadofthepack

Тренд по фрилансу

PwC сделал интересное исследование по глобальным и региональным трендам рынка фрилансеров

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

В России фрилансеры – это прежде всего молодое поколение людей. Согласно исследованию, 68% из них находятся в диапазоне от 18 до 34 лет. Постепенно идет смена поколений. Получившие первый опыт работы и при этом привыкшие к фрилансу зуммеры с их приоритетами, начинают задавать зарождающийся сильный тренд. И его стоит учитывать в будущем. 💡 А еще лучше - воспользоваться этой тенденцией. Усилению тренда фриланса способствуют два фактора из предыдущего 2020 года: пандемия, развеявшая мифы об неэффективности удаленных сотрудников, а также увеличение доли безработных специалистов на рынке труда.

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

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

@aheadofthepack

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

Как проектировать что-то с топ-менеджментом

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

1. Всегда приходи с прототипом - не приходите с белым листом, топ-менеджеры привыкли относится уже к какому-нибудь решению, а не "придумывать его". В его голове "придумывать его” - то, за что он вам платит.
2. Приходите со словами "Хотим посоветоваться", "Хотим услышать ваше мнение"
3. Для обсуждения используйте функциональную карту или концептуальную модель данных - на этих инструментах топ-менеджер готов высказываться и рисовать. На функциональной карте обычно легче проектируют топ-менеджеры ИТ, а на концептуальной модели данных - топ-менеджеры от бизнеса.
4. Используйте дорожную карту, когда вы обсуждаете что-то во времени
5. Принесите ваш «прототип» так, чтобы топ-менеджеру было легко на нем рисовать, например, в порядке опыта успешности: несколько распечатанных листов A4/A3 (это всегда на всякий случай носите); плакат; отображение с проектора на белую "доску" на которой можно рисовать или какая-то форма в которой в онлайн можно вместе рисовать (в PowerPoint есть эта функциональность) или yEd какой-нибудь для сложных концепций (там быстро можно накидать, а потом по кнопке упорядочить до красоты)...

P.S. Прототип может быть не полный, но все равно принесите его. Там где не понятно поставьте «…».

#практика #топ #архитектура #итстратегия #геронимус #лучшее
via @it_ace

💬 Комментировать

Инфраструктурная зависимость

Немного незапланированной рефлексии о будних.

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

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

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

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

Один из разумных выходов для снижения таких непросчитываемых рисков - переход в облака на SaaS, или хотя бы на IaaS в какой-нибудь дата-центр.💡Не зря есть правило - аутсорсить все, что не является основной деятельностью фирмы. Как правило затраты окупаются с лихвой.

🤔💭Интересно, насколько SaaS решения сейчас вытеснили такие пережитки нулевых и начала десятых, как внутреннюю IT инфраструктуру?

@aheadofthepack

Зачем тратить время на чужие исследовательские интервью?

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

Исследовательские интервью - лишь часть подхода Customer Development.

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

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

🍏 Как минимум можно посмотреть как другие делают эту интересную и сложную работу. Всегда найдется то, что можно подчерпнуть.

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

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

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

@aheadofthepack