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

Возможности человеческой памяти ограничены

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

У человека два вида памяти.

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

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

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

Рабочая память малоемкая и неустойчивая. Специалист по когнитивной психологии Джордж Миллер в 1956г. в книге о волшебном числе 7 предположил, что средний человек может удерживать в краткосрочной памяти около 7объектов (плюс-минус 2).

Если дизайн разработан таким образом, что пользователю в рабочей памяти требуется в течение более чем 7секунд держать более 3объектов или 1объект в течение более чем 70секунд, то будут появляться ошибки: информация в рабочей памяти очень легко теряется.

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

У долговременной памяти множество слабых мест и она ненадежна. Память этого вида во многом отличается от рабочей. Объекты в долговременной памяти хранятся в мозгу, распределенные по многим его участкам. Хранящаяся в долговременной памяти информация не исчезает, но постепенно затухает, теряя силу. (Джонсон, 2014; подробнее в книге.)

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

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

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

Факторы, влияющие на работу памяти

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

Перечислю некоторые факторы, которые влияют на рабочую память:

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

• Сходство и путаница. Если объекты похожи, их можно легко объединить в одну порцию.

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

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

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

Факторы, влияющие на получение информации из долговременной памяти:

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

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

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

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

Мы уже выяснили, что рабочая память хранит мало и недолго, а у долговременной памяти много слабых мест и на первых этапах запоминания она ненадежна. Дизайнер должен помочь пользователю запомнить важную информацию до момента, когда она понадобится. Нельзя требовать запоминать состояние системы или выполненное действие. Вот некоторые подходы, которые помогут снизить нагрузку на рабочую память пользователей (Lee, Wickens, Liu, Boyle, 2017; подробнее в книге):

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

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

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

• Буквы вместо цифр. Обычно буквы человеку запомнить проще, чем цифры. Поэтому, например, рабочий номер телефона лучше записывать не как 467-968-2378, а как 467-YOU-BEST.

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

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

Чтобы дизайн помогал работе долговременной памяти, нужно в первую очередь избегать разработки систем, которые повышают нагрузку на память этого вида. Для этого можно применять следующие подходы (Lee, Wickens, Liu, Boyle, 2017; подробнее в книге) как вы увидите, именно так работают многие интерактивные системы.

• Поощряйте пользователей использовать информацию регулярно. Частое воспоминание повышает силу информации в долговременной памяти.

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

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

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

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

• Единообразная работа в рамках системы и с другими приложениями. Чем единообразнее работа разных функций и действия с объектами разных типов, тем меньше пользователю нужно запоминать. В интерфейсе со множеством исключений и низким уровнем единообразия между функциями и объектами различных типов пользователю приходится хранить в долговременной памяти особенности каждой функции и каждого типа объектов, а также правильный контекст использования. Необходимость запоминания большого количества информации затрудняет изучение таких интерфейсов. (Джонсон, 2014; подробнее в книге.)

Дизайн должен соответствовать знакомой пользователю ментальной и концептуальной модели. Простой пример: круглые переключатели позволяют выбрать один вариант, флажки в квадрате несколько. Источник https://www.justinmind.com/blog/mental-models/

Литература:

John D Lee, Christopher D. Wickens, Yili Liu, Linda Ng Boyle (2017). Designing for People: An Introduction to Human Factors Engineering 3rd Edition.

Джефф Джонсон (2014). Умный дизайн. Простые приемы разработки пользовательских интерфейсов.

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимаетсялокализацией игрприложений и сайтовна 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаемрекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

В 2021 году половина российских компаний планирует нанимать временный персонал для привлечения к проектной деятельности. Это показал опрос Hays, в ходе которого высказались почти 5 тысяч респондентов. 15% из них планирует за счет аутстаффинга оптимизировать свои расходы. 7% опрошенных испытывают сложности с поиском подходящих сотрудников в штат.

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

Глеб Корсунов, CBDO Holyweb, обсудил с Михаилом Кебичем, руководителем разработки публичного облака Mail.ru Cloud Solutions, какие существуют опасения относительно аутстафф-подрядчиков, как безболезненно подключить внешних специалистов к инхаус-команде и как влиять на их мотивацию.

Приятного чтения!

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

Функция аутстаффинга дополнять, усиливать или заменять команду заказчика. Это рабочий инструмент, у которого есть свои плюсы и минусы. Мы в Mail.ru Cloud Solutions им пользуемся и нам он помогает.

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

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

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

С помощью аутстаффинга мы решаем задачи управления ресурсами быстро привлечь под задачу дополнительные руки и так же быстро сократить этот ресурс, если он не нужен здесь и сейчас. Если кто-то из аутстафферов уйдет, на наш бизнес это никак не повлияет. У нас своя разработка: все, кто отвечает за предоставление сервиса в режиме 24/7, работают во внутренних командах Mail.ru Cloud Solutions. На аутстафф мы стараемся отдавать полностью отчуждаемые задачи, чтобы они находились в зоне ответственности одной команды разработки от и до. Это могут быть сложные и объемные проекты на нескольких месяцев. Впрочем, мы всегда стремимся уменьшать циклы разработки стандартный спринт для инхаус-команды составляет две недели, и аутстафф двигается в том же ритме.

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

Как отношение инхаус команды к аутстафферам влияет на качество сотрудничества?

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

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

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

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

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

Как доверять, но проверять?

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

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

Если для эффективной работы программисту нужно играть на балалайке или в Dota пожалуйста. Оценивать мы будем результат.

Эта позиция в той же степени распространяется и на внутренних сотрудников Mail.ru Cloud Solutions.

Аутстафф-сотрудники не такие мотивированные, как штатные? Так ли это и как можно на это влиять?

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

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

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

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

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

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

Если аутстаффер работает внутри команды, то мы в Mail.ru Cloud Solutions оцениваем его точно так же, как и штатных сотрудников. Онбординг новых специалистов занимает столько же времени, они полностью интегрируются в команду и работают по той же системе и с теми же KPI, что и инхаус-разработчики. КПД каждого отдельного разработчика измеряется в зависимости от сложности сервисов и задач, с которыми работает его команда. Быть эффективным и попадать в сроки команды невозможно без качественной коммуникации.

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

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

Как найти баланс при подборе разработчиков не перегнуть палку и не проглядеть подходящих кандидатов?

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

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

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

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

Остались вопросы? Пишите в комментарии или Глебу в Facebook ответим всем.

Если вы хотите присоединиться к команде Mail.ru Cloud Solutions: прямо сейчас открыты вакансии Python/Go-разработчика в команду PaaS и Go-разработчиков в команды объектного хранилища и IAM.

Полный и актуальный список вакансий MCS.

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

История, описанная ниже, перевод статьи с Medium.com , которая вызвала бурное обсуждение внутри коллектива моей компании (я даже сохранил для вас некоторые комментарии). Но, я уверен, рассказ покажется до боли знакомым очень многим читателям Хабр.

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

Начальник отдела разработки созвал всех на собрание:

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

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

Что вы имеете в виду под переписать код? спрашиваете вы.

Глава отдела разработки пожимает плечами: Мы используем мультитул версии 1.6, говорит он, но версия 4.3 была выпущена на прошлой неделе, поэтому мы должны быть как минимум на версии 4.x.

"Хорошо, скажете вы, повлияет ли это на фичи, которые мы уже добавили в список?"

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

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

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

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

Вы не собираетесь выпускать пар при помощи пассивно-агрессивных комментариев. Все остальные так делают.

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

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

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

Руководитель мобильной разработки Мегаплана, Игорь Суховерхов

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

Через неделю вы снова встречаетесь. "Как продвигаются дела с кодом?", спрашиваете вы.

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

Проходит месяц. Вы снова встречаетесь:

"Как идут дела?", спрашиваете вы.

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

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

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

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

Руководитель мобильной разработки Мегаплана, Игорь Суховерхов

Младший разработчик объясняет несколько преимуществ Spasm. Это MVVM(Model-view-viewmodel) паттерн, тогда как Doohickey это MVC(model-view-controller) паттерн, который действительно старомоден. Вы ждете своей очереди и вежливо спрашиваете о некоторых срочных доработках, которые нужно добавить в продукт.

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

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

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

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

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

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

1) Делайте всё вовремя и не затягивайте с обновлениями.

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

3) Считайте все в деньгах. В какой-то момент стоимость поддержки начнет кратно расти это знак, что пора что-то делать.

4) Если проект хочет развиваться и масштабироваться, а его код устарел и не поддерживается еще один сигнал, что пора заняться рефакторингом

Вы смотрите на экран. Но даже на надеетесь увидеть там законченную работу.

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

Вы смотрите на экран. Но даже не надеетесь увидеть законченную работу.

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

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

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

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

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

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

Руководитель мобильной разработки Мегаплана, Игорь Суховерхов

Креативный директор не согласна: Но ведь сейчас прекрасная возможность! Затем, резко сменив тему: Поговорим об аналитике?

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

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

Я предлагаю использовать Analogix, говорит креативный директор. Начальник отдела разработки быстро изучает этот сервис и видит, что для Spasm есть плагин, так что он за.

"И можем ли мы добавить его на текущий сайт, чтобы сравнить аналитику?" спрашивает креативный директор.

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

Из-за переключения контекста?" предполагаете вы.

Да, говорит он, это добавляет когнитивную нагрузку.

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

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

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

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

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

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

Залог хорошего планирования:

1) Точность оценки задач. В scrum это приходит с опытом: каждый новый спринт команда всё лучше и лучше оценивает свои возможности.

2) Дедлайны и сроки работа не должна быть бесконечной.

3) Измеримость конечного результата.

Ну, и конечно хороший проджект-менеджер :)

На следующей встрече начальник отдела разработки сообщает вам, что уходит на работу в Dunkr. Это стартап. Как Uber, только для одежды, говорит он. Судя по всему, они используют Spectral Spasm. Это новая версия Spasm, которая гораздо круче предыдущей. Он в восторге от новой должности. Мне даже дали опционы на акции, говорит он вам.

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

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

Руководитель мобильной разработки Мегаплана, Игорь Суховерхов

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

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

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

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

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

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

В оригинальной статье на сайте Medium, хотя и написанной от лица мужского пола, можно сказать от библейского первого человека Адама, в пример топового разработчика приводится девушка, которая в 11 лет сделала свой сайт, а к 23-м годам стала миллиардером. Судя по тому, что у нас в компании девушки-разработчики большая редкость (их всего две), а мы типичная IT-компания, для адаптации к местным реалиям пришлось превратить ее в парня. Получилось почти как у Киплинга. Помните, пантера Багира в оригинальных книгах был мачо-мальчиком, а в советском мульте превратился в супердевочку с голосом актрисы Касаткиной.

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

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

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

Тысячи URL-адресов были потеряны

Работая в крупном финансовом учреждении, я разработал систему для очистки неиспользуемых маршрутов на сетевом уровне F5. Пул маршрутов F5 мог поддерживать примерно 5000 URL-адресов. Затем он засорялся. Моя система автоматизировала процесс мониторинга трафика по этим URL-адресам, уведомляла владельцев о неиспользуемых ресурсах и в конечном итоге очищала их. Она не давала системе F5 выйти из строя и освобождала от ручной обработки операций.

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

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

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

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

Как это могло случиться?!

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

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

Что я вынес из этой ситуации?

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

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

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

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

База данных и учетные записи должны быть доступны по умолчанию только для чтения, должны иметь четкие стратегии резервного копирования и восстановления. Например, на моей следующей работе разработчик случайно удалил файлы из корзины prod S3. Если бы у нас не было стратегии управления версиями S3, которую я установил всего за неделю до этого (она отключена по умолчанию, черт возьми, Amazon!), мы могли потерять ее навсегда.

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

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

Отправил письмо с кодом не сотруднику компании

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

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

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

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

Как это могло случиться!?

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

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

Что я вынес из этой ситуации?

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

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

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

Потерял работу во время пандемии

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

Однако к июлю стало ясно, что нам нужно или сокращать команду, или наш корабль пойдет ко дну. В 11:30 генеральный директор лично отправил мне сообщение в Slack со зловещей просьбой позвонить ему в 12:00. В 12:15 меня уволили. Цитирую: Адам, мы вынуждены немедленно отпустить вас. Мы считаем, что вы хорошо поработали, однако из-за сложных условий мы сокращаем персонал. Я был одним из 15 человек, бесцеремонно уволенных в тот день, без предупреждения, выходного пособия, даже без пяти минут, чтобы попрощаться с командой (учетная запись Slack была отключена во время разговора).

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

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

Как это могло случиться!?

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

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

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

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

Что я извлек из этой ситуации?

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

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

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

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

P.S. Позор тем компаниям, которые оставляют соискателей без обратной связи.

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

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

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

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

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

Кто и чему учится в рамках аутсорсинговой бизнес-модели:

• Основатели и менеджеры бизнесу и управлению.

• Инженеры разработке и инженерной культуре.

• Продавцы длинным и сложным B2B-продажам, где нужно вырабатывать доверие, продавая воздух.

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

После развала Союза у нас не было опыта в бизнесе, не хватало инженерных знаний всё это мы получили во многом благодаря аутсорсингу!

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

Тот же EPAM, который некоторые до сих пор по-привычке считают аутсорсинговой компанией, уже давно совершил разворот к сервисно-инжиниринговой модели. Как пишут Ведомости, если до 2005 г. около 80% заказов этой компании приходилось на аутсорсинг в разработке продуктов для технологических компаний, то сейчас на подобные заказы приходится около 20%. Сам Аркадий Добкин, основатель EPAM, так объясняет этот термин в прошлогоднем интервью журналу Большой:

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

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

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

Зрелость индустрии соответствует зрелости государства и общества. Поэтому логично, что на данном этапе мы (IT-компании в Беларуси) занимаемся аутсорсингом, как и наши соседи в Украине, России, Болгарии, Молдове и т.д. Даже Польша, Чехия, Литва и Румыния все еще входят в список стран для ИТ-аутсорсинга, хотя там ситуация постепенно меняется. А в таких странах как Дания и Германия структура бизнес-моделей и компаний уже совсем другая. Это положение дел обусловлено стоимостью оплаты труда, индексом экономического развития и другими параметрами, поэтому не стоит думать, что мы все-еще занимаемся аутсорсингом, потому что кого-то из наших инженеров несправедливо недооценили.

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

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

Трансформация аутсорсинга

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

Давайте рассмотрим, в какие бизнес-модели они используют:

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

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

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

Как на это смотрят сами руководители компаний из Западной Европы? Мой коллега Зоран Вельковски, основатель датской инжиниринговой компании TekPartner, так прокомментировал перспективы сотрудничества в отрасли:

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

Только компании с огромным бюджетом на НИОКР, такие как Apple, Tesla, Microsoft и Google, могут позволить себе полную вертикальную интеграцию. Всем остальным нужна внешняя помощь, т.е. аутсорсинг всех видов деятельности, которые не относятся к основной компетенции компании.

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

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

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

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

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

Рецепты

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

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

2. Дополнять свои услуги продуктами / платформами / решениями.

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

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

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

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

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

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

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

Про возраст

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

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

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

Про опыт

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

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

Ну и всё это на фоне роста основных скиллов.

Если говорить конкретнее, то у нас есть заказчики из финтеха, есть просто технологические компании, есть ecommerce с посещалкой в несколько миллионов. Сомнительных проектов у нас просто нет, мы не беремся за сайты Свидетелей Иеговы, как тутписали в комментах:)

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

Михаил, QA-специалист Holyweb

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

Про стабильность

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

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

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

Поэтому аутстафф-компания (по сути сервисная) от такого защищает. Отвалился один проект перешли в другой.

Даниил, React-разработчик Holyweb

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

Про деньги

Ага, вы продаете джунов как мидлов, платите им 30К, остальное в карман! примерно так часто пишут про аутстаффинг.

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

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

Про комфорт разработчика

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

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

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

Геннадий, PHP / Node.js разработчик Holyweb

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

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

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

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

Про нелюбовь к релокейтам

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

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

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

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

Про ООО НДА

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

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

Про софт скиллы

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

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

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

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

Про то, как мы собеседуем клиентов

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

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

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

Петр, React-разработчик Holyweb

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

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

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

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

Дэннис, React-разработчик Holyweb

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

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

Итого, что дает программисту работа аутстаффером:

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

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

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

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

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

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

Понимаем, что у вас все равно остались вопросы так что пишите в комментариях или мне в Telegram.

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

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

Я Group Product Manager компании iDeals, которая создает b2b-продукт виртуальные комнаты данных (VDR). В этой статье подробно расскажу о том, как мы выстроили продуктовый процесс и что делаем на каждом из этапов.

Для чего

Продуктовый процесс:

• уменьшает субъективизм в принятии решений продуктовыми менеджерами,

• упрощает понимание того, что и в какой момент времени необходимо делать,

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

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

Продуктовый процесс

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

Идея

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

• анализа рынка и конкурентов;

• качественных исследований пользователей и клиентов (интервью, опросы и т. д.);

• количественных исследований пользователей и клиентов (Heap, Bigquery, Google analytics и т. д.);

• обратной связи от потенциальных и нынешних клиентов и пользователей;

• идей от стейкхолдеров или других команд;

• внутренних запросов от других команд;

• выводов после измерения показателей успеха.

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

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

Примеры идей:

Привет! А можно ли как-то увидеть все свои заметки из комнаты данных? Я бы хотел видеть их в одном месте, чтобы не кликать на разные файлы, для которых я их сделал.

Здравствуйте!

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

Гипотеза

Гипотеза отличается от идеи глубиной проработки. Обычно в ней 4 блока, которые по сути отвечают на следующие вопросы:

1. Какая проблема решается? Идея в формате гипотезы, которая содержит информацию об аудитории, проблеме и условиях, когда она возникает.

2. На кого повлияет? Более детальная информация об аудитории или персоне, которая испытывает проблему.

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

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

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

На этом этапе в процесс вступает приоритизация, которая призвана бороться с субъективизмом и ориентировать продуктовый процесс на работу только с самыми влиятельными и важными идеями. Для этого в iDeals мы используем модифицированный подход RICE от Intercom (Reach * Impact * Confidence / Effort), который дополнили еще одним параметром Strategy (S) и в итоге получили RICSE (Reach * Impact * Confidence * Strategy / Effort):

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

• Impact (влияние) условный коэффициент того, как сильно решение проблемы из гипотезы повлияет на пользовательский опыт аудитории. Мы используем шкалу от 0 до 3 с шагом 0.25, каждый из шагов значит силу влияния: от 0 нет влияния, до 3 влияние огромное.

• Strategy (стратегия) показывает, на сколько это решение ложится в наши долгосрочные планы. Мы используем три значения стратегии: 0,3 нет соответствия стратегии; 0,8 частичное соответствие; 1 полное соответствие.

• Effort (трудозатраты) это высокоуровневая оценка, для которой мы используем числа Фибоначчи, к которым привязаны календарные периоды: 1 до 2 недель; 3 до месяца; 5 до квартала; 8 до двух кварталов; 13 два квартала и больше (или по факту, когда оценка крайне неточна, но понятно, что решение будет очень трудозатратным).

• Confidence (уверенность) условный коэффициент уверенности во всех других показателях и может принимать значение от 0,1 до 1. Обычно мы используем шаг 0,2 для каждого показателя, в котором есть сомнения. Например, если мы не очень уверены в охвате, то уверенность 0,8, а если еще и во влиянии 0,6 и т.д.

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

Пример гипотезы:

Какая проблема решается?

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

На кого повлияет?

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

На что повлияет?

• Уменьшение расходов на отправку кодов для двухфакторной аутентификации через СМС и звонки.

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

• Повышение уровня удовлетворенности пользователей.

Как сейчас решается проблема?

Отключением двухфакторной аутентификации.

Валидация

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

Этот этап имеет два возможных пути решения:

1. У нас есть все необходимые данные для подтверждения гипотезы и движения дальше.

2. У нас нет данных для подтверждения гипотезы.

В первом случае мы проверяем ретроспективно, исходя из разных данных, которые у нас уже есть. Для этого используем типичные инструменты: Google Analytics, Heap, BigQuery; опросы для количественных данных, интервью, запросы и отзывы клиентов для качественных.

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

Окончание этапа обновленные показатели RICSE и отчеты, Excel таблицы, записи интервью и другие данные, которые подтверждают эти показатели.

Гипотезы с наибольшей приоритизацией берутся в дальнейшую проработку.

Пример гипотезы и валидации:

Гипотеза

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

Данные для валидации:

По данным за 4-й квартал 2020-го года около 30% всех проектов имеют больше одного архива в формате ZIP, RAR или 7Z, но при этом только 1.7% из проектов с архивами хоть раз использовали функцию разархивации.

Решение (PRD)

Данный этап целиком и полностью посвящен самому решению и созданию product requirements document (PRD / документ с требованиями к продукту) и состоит из следующих шагов:

• исследование рынка на предмет того, как лежащая в основе гипотезы проблема решается прямыми и непрямыми конкурентами, а также продуктами из других отраслей;

• определение персон, которые являются покупателями и пользователями решения;

• определение возможных флоу, которые являются характерными для разных персон;

• создание пользовательских историй (user stories) для понимания полной картины и всех возможных нюансов;

• обсуждение уже полученных наработок с технической командой на предмет того, является ли это все возможным, нужно ли проводить дополнительные технические исследования или создавать технические концепты (proof of concept);

• детальная проработка пользовательского опыта и интерфейса (UX / UI);

• проработки UX / UI и консультации с технической командой могут быть итеративными;

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

• определение необходимых маркетинговых активностей: коммуникация через имейл / продукт; материалы для маркетинг-сайтов, влияние на прайсинг и планы и т.д.;

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

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

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

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

Таким образом получается, что формула RISCE: React * Impact * Strategy * Confidence / Effort получает подтверждения по всем элементам и гипотезы / решения вновь приоритизируются уже учитывая все переменные в формуле.

Дорожная карта (Roadmap)

В конце каждого квартала продуктовые менеджеры вместе с инженерными менеджерами и командами составляют дорожную карту (Roadmap) на ближайший квартал для каждой технической команды (их у нас 6). В нее попадают уже подготовленные решения. Иногда и гипотезы для технической или продуктовой проработки, которые имеют наивысшие значения приоритета по RICSE.

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

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

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

Имплементация

В условиях iDeals команды работают по процессу, который очень близок к Scrum, со всеми соответствующими артефактами: итеративная разработка, ежедневные встречи по 5-10 минут для быстрой синхронизации, еженедельные встречи для обсуждений новых пользовательских историй, каждые две недели планирование очередной итерации (Спринта) и проведение ретроспективы по прошлой.

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

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

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

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

Верификация

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

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

Вывод

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

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

Как устроен продуктовый процесс в вашей компании? Делитесь в комментариях!

P.S. Спасибо Дмитрию Ковалю за помощь в подготовке статьи.