На шаг впереди

04 May 2021 10:38

Испорченный телефон

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

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

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

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

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

@aheadofthepack

На шаг впереди

19 Apr 2021 09:17

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

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

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

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

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

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

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

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

@aheadofthepack

На шаг впереди

09 Apr 2021 08:33

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

На шаг впереди

02 Apr 2021 08:29

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

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

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

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

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

@aheadofthepack

На шаг впереди

17 Mar 2021 09:55

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

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

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

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

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

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

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

@aheadofthepack

На шаг впереди

04 Mar 2021 08:30

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

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

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

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

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

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

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

@aheadofthepack

На шаг впереди

18 Feb 2021 07:54

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

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

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

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

На шаг впереди

05 Feb 2021 06:29

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

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

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

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

На шаг впереди

28 Jan 2021 07:01

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

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

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

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

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

@aheadofthepack

На шаг впереди

11 Jan 2021 06:28

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

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

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

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

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

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

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

@aheadofthepack

На шаг впереди

16 Dec 2020 07:23

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

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

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

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

@aheadofthepack

На шаг впереди

08 Dec 2020 07:48

Причем тут Маслоу?

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

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

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

@aheadofthepack

На шаг впереди

24 Nov 2020 07:16

Зацикленность на технологиях

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

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

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

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

@aheadofthepack

На шаг впереди

05 Nov 2020 06:25

Продуктовая и проектная диверсификация

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

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

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

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

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

@aheadofthepack

На шаг впереди

21 Oct 2020 12:39

Два подхода к чтению книг

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

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

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

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

@aheadofthepack

На шаг впереди

28 Apr 2021 08:12

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

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

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

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

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

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

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

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

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

@aheadofthepack

На шаг впереди

09 Apr 2021 08:33

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

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

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

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

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

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

На шаг впереди

08 Apr 2021 12:00

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

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

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

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

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

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

@aheadofthepack

На шаг впереди

25 Mar 2021 07:54

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

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

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

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

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

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

@aheadofthepack

На шаг впереди

11 Mar 2021 08:00

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

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

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

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

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

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

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

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

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

@aheadofthepack

На шаг впереди

26 Feb 2021 12:16

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

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

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

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

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

@aheadofthepack

На шаг впереди

16 Feb 2021 07:35

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

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

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

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

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

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

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

@aheadofthepack

На шаг впереди

04 Feb 2021 06:56

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

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

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

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

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

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

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

@aheadofthepack

На шаг впереди

22 Jan 2021 13:50

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

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

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

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

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

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

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

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

@aheadofthepack

На шаг впереди

24 Dec 2020 14:09

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

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

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

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

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

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

@aheadofthepack

На шаг впереди

15 Dec 2020 08:02

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

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

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

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

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

@aheadofthepack

На шаг впереди

27 Nov 2020 10:26

Сегодня у нас видеопредставление спикера!
Александр Кузовлев
Руководитель проектов,
ВА\SA аналитик в Третий Пин – агентство разработки электроники и встроенных систем на заказ, – рассказал про свое выступление 17 декабря 2020 года на Аналитическом марафоне #3:

https://youtu.be/zFHXM_6AFOs

На шаг впереди

13 Nov 2020 10:25

Возврат к средней величине

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

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

Вы видите это в числах, если внедрены "показометры" производительности, KPI или что-либо еще. Как пример, метрика Velocity в методологии Scrum.

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

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

@aheadofthepack

На шаг впереди

29 Oct 2020 10:44

Польза должностной инструкции

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

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

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

Я тоже одно время ломал голову над задачкой, пока не нашел другой, правильный подход. IEEE разработала документ – 📚 Software Engineering Competency Model (SWECOM). 👉aheadofthepack/hEapaEO6U6">Далее...

@aheadofthepack

На шаг впереди

09 Oct 2020 11:29

One way ticket

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

Процессы и инструменты
Компании, вовремя внедрившие процессы и инструменты для удаленной работы выглядят казалось бы «на коне». Наконец появляется возможность отказаться от устаревших оффлайновых KPI, такие как 40 списанных часов в неделю, или прихода к 10:00 в офис и сосредоточится на значимых результатах в соответствии с выбранной методологией управления. Но диджитализация - первая часть возможного успеха.

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

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

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

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

Полезные инструменты
Кто еще не понял, куда стремится мир IT? Пока есть время можно изучить некоторые полезные SaaS сервисы для совместной удаленной работы. Надеюсь, что вы уже работаете с ними:

✔️Визуальные доски с шаблонами Miro Mural
✔️Системы управления проектами YouTrack Trello Jira
✔️Мессенджеры для командной работы Slack MS Teams
✔️Системы контроля версий Github Bitbucket
✔️и, конечно же конференции Zoom

@aheadofthepack