Разработка программного обеспечения

Из известного мультфильма:

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

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

Что ж, чтоб не горело, там где сидело, предлагаю разработать некую систему оценок

Дано:

1. многие менеджеры не любят диапазоны в оценках
2. [ходят слухи] на задачу тратится все отведенное время
3. слишком много вариантов для оценки (1 час, 2 часа, 3, 4, 5, n)
4. роль тимлида не учтена

Один известный дизайнер* как-то ввел термин единица смысла, уточнив при этом: " а именно, выписать их на листочек Листочек в редких случаях окажется заполненным до середины, даже если писать крупным почерком." Ecли предположить, что середина листочка это приблизительно десять пунктов, путем нехитрых вычислений постановим (почему, собственно, и не постановить :): любая задача это два дня. Точка.

На любую задачу менеджера смело называйте оценку в два дня если задача большая, всегда можно показать, что уже сделано (за два дня), если небольшая дописать тесты, написать документацию, почистить код. Тут идея в том, что за два дня нужно обязательно сделать что-то законченное, что-то самостоятельное (какой бы смысл вы ни вкладывали в это слово). За два дня можно делать таски, которые, как сказал один известный румын** на одной известной однобуквенной conf [перевод мой]: хочется видеть пул-реквесты, которые огонь, которые прям хочется вмержить. Двухдневные таски хороший инструмент. Но что делать, если хочется запланировать 153.75 часов, а писать слишком длинный список лень? Все верно та-дам, создать большую задачу.

Большая задача это задача, которая терпима к ошибке (к одной большОй ошибке или к нескольким маленьким ошибочкам :) То есть мы делаем таску, поняли, что ошиблись, откатились к нулевому дню, делаем таску заново. Итого, просуммировав: два дня + ошибка + два дня = равно четыре дня. Большая задача это четыре дня. (Другими словами, на большую таску можно смотреть как на таску с большим кол-вом неизвестных при старте). Все это прекрасно, скажете вы, но что делать, если хочется пофиксить багу сегодня, сейчас (ну, то есть, вчера)? Та-ДАм маленькая задача.

Берем рабочий день разработчика, это где-то 8 (7,6,5...) часов и делим на кол-во задач, которые стандартный (он же средний) разработчик может сделать (тут важно не забыть время на все pr change requests). Путем медитации и калькулятора получаем 3 часа, менеджеру говорим 4 часа, так как это полдня работы. Итого, маленькая задача это 4 часа.

Мне кажется, роль тимлида как-то потеряна, как-то тупо не учитывается при эстимейтах (банально, вы скажете ну в принципе да :) Менеджерам мы сообщаем оценки в терминах трех задач, но тимлиду говорим, что мальнькая задача это 0-4 часов, задача (она же таска) это 0.5-2 дня, большая задача 2-4 дня. И тут открывается дзен тимлида, капитана судна, главного-преглавного. Если разработчик постоянно выполняет таски по верхней границе эстимейта командный дух похерен.

Что же делать? Да *** его знает, наверно, смотреть Что? Где? Когда? и учиться-учиться-учиться.

* www.artlebedev.ru/kovodstvo/sections/148
** Andrei Alexandrescu, DConf

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

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

С чем едят АПК Безопасный город

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

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

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

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



По существу

Обратимся к нормативным документам. Единые требования к техническим параметрам сегментов аппаратно-программного комплекса Безопасный город (28.06.2017) лаконично констатируют, что в ядре платформы Безопасный город должно быть 2 ключевые подсистемы: Региональная интеграционная платформа (РИП) и Единый центр оперативного управления (ЕЦОР). Просто, недешево и минимально функционально. Только анализ данных и управление, остальное интеграции.

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

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

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

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

Добавим ингредиентов

Вспомним, что сейчас для закладки Безопасного города нужно только 2 ключевые подсистемы: РИП для создания единого информационного пространства и ЕЦОР для управления потоками данных и управления ситуацией. Наш опыт разработки и внедрение АПК Безопасный город говорит о том, что этого крайне мало и в ядро системы необходимо добавить несколько критически важных подсистем. Без этих ингредиентов кашу Безопасных городов нормально не заваришь. Критически-важную инфраструктуру надо создавать по новому рецепту.

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

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



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

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

Была проведена работа по обеспечению взаимодействия с системами видеоаналитики различных вендоров, включая систему распознавание номеров (ГРЗ), которая работает на обычных камерах видеонаблюдения. Далее ее сработки передаются в АИС регионального подразделения МВД. В целом в систему были заведены потоки всего спектра имеющихся в регионе устройств: от аналоговых камер до рубежей системы фотовидеофиксации. Апогеем данного проекта является интеграция видеопортала и РИП АПК БГ. Это позволило передавать информацию о всех камерах региона, транслировать онлайн-видео, архив, а также передавать события по срабатыванию видеоаналитики в единый центр.

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

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

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



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

Что станет изюминкой?

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

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

Но как можно предсказать будущее и проверить, что подсистема принятия решений работает? Здесь приходят на помощь наработки министерств РФ с многочисленными методикам анализа ситуаций и расчета показателей. Основаны они на реальном опыте и дают разработчикам всю необходимую информацию о формулах и особенностях расчета тех или иных ситуаций.
Интеграция нескольких источников данных в ядре Безопасного города помогает получить актуальные на данный момент величины (объем выбросов, тип вещества, направление ветра, температура) и на основании них выстроить наиболее эффективный план реагирования, алгоритм действий.

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



И на десерт

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

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

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

Делаем систему параллелизма надёжнее

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

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

Сгенерированная инструментом LTSA диаграмма состояний

---

Что это за язык FSP?

Finite state processes (FSP) это абстрактный язык, на котором разрабатывают системы конкурентных процессов.

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

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

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

Как с помощью алгебры процессов (FSP) описать конкурентные процессы

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

Вначале проанализируем принтер

• В принтер помещается только три листа, студенты могут распечатать до трёх документов;
• Если листов нет, принтер нужно заполнить ими.

const MIN_SHEET_COUNT=1const MAX_SHEET_COUNT=3range DOC_COUNT=MIN_SHEET_COUNT .. MAX_SHEET_COUNTrange SHEET_STACK=0 .. MAX_SHEET_COUNTPRINTER(SHEETS_AVAILABLE = MAX_SHEET_COUNT) =  ( start -> PRINTER_AVAILABLE[MAX_SHEET_COUNT]),  PRINTER_AVAILABLE[sheets_available: SHEET_STACK] = if   (sheets_available > 0)  then (acquire -> print[DOC_COUNT] -> release -> PRINTER_AVAILABLE[sheets_available - 1])  else (empty -> refill_printer -> release -> PRINTER_AVAILABLE[MAX_SHEET_COUNT]).

Процесс PRINTER

Когда пользователь (студент или техник) получает принтер, принтер печатает документ, отдаёт его пользователю и возвращается в исходное состояние. Это называется повторяющимся поведением.

Как анимировать процесс

Чтобы анимировать процесс, сначала скомпилируйте (compile [1]) код, затем перейдите на вкладку draw. Нажмите кнопку animatе [2].


Анимация процесса PRINTER

В аниматоре видно, что принтер напечатал три документа и пошёл на заправку. Заправлять принтер должен техник. Эту часть мы проанализируем позже.

Печатающий документы студент

Код на FSP можно написать при помощи условных процессов (if, then, else). DOCSTOPRINT = 3 это переданный процессу параметр 3. Процесс PRINT начинается с 0. Doc_count это метка индексированного действия, которая ведёт к этому действию: PRINT [doc_count].

STUDENT(DOCS_TO_PRINT = 3) =  PRINT[0],PRINT[doc_count: 0 .. DOCS_TO_PRINT] = if (doc_count < DOCS_TO_PRINT)then ( acquire -> print -> release -> PRINT[doc_count + 1]  )else ( terminate -> END ).

Процесс STUDENT с условным процессом

Тот же самый процесс можно написать и с помощью защищённых процессов.

STUDENT(DOCS_TO_PRINT = 3) =  PRINT[0],PRINT[doc_count: 0 .. DOCS_TO_PRINT] = (  when (doc_count < DOCS_TO_PRINT)  acquire -> print -> release -> PRINT[doc_count + 1] |  when (document_count == DOCUMENTS_TO_PRINT) terminate -> END ).

Процесс STUDENT с защищённым процессом


Анимация процесса STUDENT

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

TECHNICIAN = (empty -> refill_printer -> release -> TECHNICIAN | terminate -> END) .

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


Анимация процесса техника

Наконец, давайте посмотрим на составной процесс

• Составной процесс должен быть синхронизирован со всеми подпроцессами, для этого можно определить набор действий с именем PRINT_Actions.
  
• terminate/s1.terminate это перемаркированное действие. С помощью мы переназначаем действие s1.terminate, чтобы просто завершить процесс. В противном случае аниматор покажет s1.terminate, s2.terminateиtcn.terminate.
  
• Чтобы синхронизировать пользователей с PRINTER, можно использовать взаимоисключающий общий ресурс.
  

|| SHARED_PRINTER = (s1: STUDENT(2) || s2: STUDENT(3) || tcn : TECHNICIAN || All_Users :: PRINTER)

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

const MIN_SHEET_COUNT=1const MAX_SHEET_COUNT=3range DOC_COUNT=MIN_SHEET_COUNT .. MAX_SHEET_COUNTrange SHEET_STACK=0 .. MAX_SHEET_COUNTset All_Users = {s1, s2, tcn}set PRINT_Actions = {acquire, print, release, empty}PRINTER(SHEETS_AVAILABLE = MAX_SHEET_COUNT) = PRINTER_AVAILABLE[MAX_SHEET_COUNT],PRINTER_AVAILABLE[sheets_available: SHEET_STACK] = if   (sheets_available > 0)then ( acquire -> print -> release -> PRINTER_AVAILABLE[sheets_available - 1]  )else ( empty -> release -> PRINTER_AVAILABLE[MAX_SHEET_COUNT] ).STUDENT(DOCS_TO_PRINT = 1) =  PRINT[0],PRINT[doc_count: 0 .. DOCS_TO_PRINT] = if   (doc_count < DOCS_TO_PRINT)then ( acquire -> print -> release -> PRINT[doc_count + 1]  )else ( terminate -> END )+ PRINT_Actions.TECHNICIAN = (empty -> refill_printer -> release -> TECHNICIAN | terminate -> END) + PRINT_Actions.|| SHARED_PRINTER = (s1: STUDENT(2) || s2: STUDENT(3) || tcn : TECHNICIAN || All_Users :: PRINTER) / {terminate/s1.terminate,terminate/s2.terminate,terminate/tcn.terminate}.

Составной процесс системы принтера

Я надеюсь, что этот материал поможет вам в изучении параллелизма на FSP.

---

• Профессия Data Scientist
• Профессия Data Analyst
• Профессия Java-разработчик
• Курс по JavaScript

Один из криминальных персонажей популярного фильма:
Не мы такие жизнь такая

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

Как-то в другой компании решили портировать команду в столицу. Часть уже была в Москве, оставалось дело за малым. Габриэлю предложили переехать в столицу или пойти в свободное плавание. Далее история с пабликом, прохладным письмом давайте решать приватно и обсуждением в соц. сетях. В итоге Габриэля оставили в провинции, так как соц сети решают :)

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

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

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

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

В этом посте расскажем, как мы в компании Автомакон применяем успешные практики из Lean Startup (несмотря на то, что многие наши проекты вполне сформировались и устоялись), с какими проблемами сталкиваемся и как с ними справляемся.

У ВкусВилл есть книжный клуб для сотрудников, в рамках которого часто обсуждаются те или иные книги. И нас часто приглашают поучаствовать в нем. На одном из таких собраний обсуждалась книга Эрика Риса Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели.



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

Работа по классике

С самого начала проекта Тилси началось выстраивание платформы с космическими требованиями:

• Высоконагруженная система;
• Всё пишем на Golang;
• Создание теоретических бизнес-процессов.

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

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

Работа по линам

Вот что сделали:

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

Кроме этого мы использовали подход Lean Startup в Зеленой линии, совместном проекте ВкусВилла и Перекрестка по запуску новой линейки натуральных молочных продуктов с ультракоротким сроком годности. Он так и назывался, Маркет. Зеленая Линия В рамках проекта мы протестировали много гипотез. Подтвержденные гипотезы ценности позволили сэкономить кучу денег и времени, а неподтвержденные не тратить ресурсы на тупиковые направления.

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

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

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

На чём стоит Lean Startup

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

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

Не дешево, а экономно

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

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

Суть подхода

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

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

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

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

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

Соответствует ли продукт нуждам потребителей?

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

Как потребители решали подобную проблему раньше?

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

Какие издержки потребители сегодня несут из-за этой проблемы?

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

Нужно ли адаптировать или изменить ваш продукт?

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

Если точно всё ОК, то переходим к пятому вопросу.

Готовы ли вы масштабировать его?

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

Осилит ли компания масштабирование? Хватит ли времени и денег, рук разработчиков, потянет ли инфраструктура возросшую нагрузку?

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

Непрерывность развития

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

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

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

Гибкость

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

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

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

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

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

А руль дает вам возможность подстроиться под то, что уже точно случилось

Погодите, это же постоянный MVP

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

Это и есть бережливость.

Что еще важно

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

Работайте с обратной связью. Это постоянный статус вашего проекта.

Эксперименты. Не бойтесь проводить их снова и снова. Посмотрите, сколько больших компаний вокруг используют A\B-тестирование. Вспомните, сколько разных версий интерфейса Facebook прямо сейчас показывается различным сегментам пользователей. Это все эксперименты, это все проверки тех или иных гипотез.

Это постоянные инновации, которые обеспечивают постоянный прогресс.

Итого

Настоятельно рекомендуем обратить внимание на концепцию Lean Startup. Из IT вы или нет, большие у вас бюджеты или собственные сбережения на продукт, методология пригодится.

Вот наши выводы от использования подхода на практике:

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

Кстати, мы сейчас активно расширяем команду, которая активно применяет Lean-подход. Вот тут можно посмотреть полный перечень вакансий hh.ru / наш карьерный сайт

Будем рады ответить на ваши вопросы.

Содержание

Введение. О чем эта статья
Цели и дисклеймеры
Часть 1. Хороший продукт
Часть 2. Пользовательский опыт (UX). Что это?
Часть 3. Архитектура выбора
Часть 4. Архитектор выбора
Часть 5. Когнитивные искажения и Пользовательский опыт
Ссылка на полную версию UX CORE (105 примеров использования когнитивных искажений в менеджменте команд и продуктов)
Часть 6. Наши дни
Часть 7. Не только искажения
Часть 8. Эпилог
Часть 9. Материал, качественно дополняющий эту статью

Введение. О чем эта статья

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

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

В какой-то момент своей жизни я перепрофилировался из технического специалиста в IT-сфере, коим я проработал около 6 лет (LAN/WAN/DevOps/InfoSec), в Product Manager-а. Моей основной деятельностью на этой должности является анализ ожиданий и принятых решений пользователей с целью создания более комфортного и желанного продукта.

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

Цели и дисклеймеры

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

• показать четкие доказательства важности глубоких знаний в психологии для работы в качестве менеджера по продукту;
• дать определение понятию UX (Пользовательский опыт) с позиции психологии и поделиться наиважнейшим источником знаний для создания качественного UX;
• показать механизм оценки грамотности продакт менеджеров (и не только);
• побудить инвесторов больше инвестировать в продукты, в основе которых лежит когнитивная психология и поведенческая экономика;
• предоставить продакт менеджерам дополнительные аргументы в поддержку их идей, которые, часто являясь верными, увы, блокируются техническими специалистами из-за непонимания полной картины и технического склада ума;
• показать с другого угла скучные исследования, которые пылятся на полках библиотек, акцентируя чрезвычайную важность этих материалов для будущего разработки ПО;
• побудить психологов и экономистов взглянуть в сторону продакт менеджмента как возможной опции смены карьерного направления. Мир IT нуждается в вас гораздо больше, чем в диванных аналитиках и псведо-менеджерах с MBA и PMP.

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

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

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

Часть 1. Хороший продукт

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

Итак, чуть выше я убрал вопросы про рынки, конкурентов и целесообразность продукта, потому что я исхожу из того, что качественный продукт это, прежде всего, продукт без внутренних противоречий. Такой продукт идеально связан как идеологическими его составляющими (история создания, его миссия, все использованные изображения, текстовые и печатные материалы используемые для его разработки и продвижения и прочее), так и техническими (back end, пользовательский интерфейс, элементы взаимодействия и дизайн, бизнес цвета, инструкции для работы службы поддержки клиентов, tone of voice of the company и много другого).

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

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

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

Часть 2. Пользовательский Опыт (UX). Что это?

Так как на данный момент понятие UX гораздо чаще относят к UI дизайну, моим оппонентом в обсуждении данного вопроса будет Джо Натоли. Джо ветеран-дизайнер с опытом работы более 30 лет, один из самых популярных в мире IT экспертов по UXD (User Experience Design), автор ряда книг, а также самых популярных видео-курсов по UX на Udemy. Натоли провел более тридцати лет консультируя по вопросам дизайна пользовательского опыта (UXD) компании из списка Fortune 100, 500 и правительственные организации. На своем вебсайте он называет себя User Experience Evangelist, значит, я могу ссылаться на его утверждения, высказанные публично в его книгах и видеоуроках.

В одном из своих уроков, где господин Натоли объясняет понятие User Experience, он ссылается на Питера Мерхольца:

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

Другой UXD эксперт Билл ДэРушэ (Старший продакт менеджер / Workflow Experience Lead at Zendesk). В обсуждении UXD говорит следующее: Для UXD даже не нужен экран. UXD это любое взаимодействие с любым продуктом, любым элементом, любой системой .

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

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

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

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

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

Часть 3. Архитектура Выбора

Понятие архитектура выбора популяризировалось после совместного труда Ричарда Талера и Касса Санстейна над Теорией Подталкивания. Вместе они написали книгу Подталкивание (англ. Nudge Theory), которая позволила множеству разных специалистов, ответственных за создание выбора для пользователей, взглянуть на свою работу под новым углом. Чтобы читатель понимал значимость вышеуказанных персон, приведу здесь их краткое описание:

Касс Санстейн со-автор теории подталкивания. После выхода книги Подталкивание президент Обама предложил Санстейну место в Отделе информации и регуляторной политики. Это дало исследователю широкие возможности внедрять идеи психологии и поведенческой экономики в работу правительственных учреждений. 10 сентября 2009 года Санстейн был назначен на пост главы OIRA, которое является частью Административно-бюджетного управления Администрации президента. OIRA осуществляет надзор за реализацией государственной политики и рассматривает проекты нормативных актов. Пост главы OIRA считается одним из наиболее влиятельных, учитывая его возможность влиять на тексты принимаемых законов. СМИ неофициально называют этот пост regulatory czar. OIRA Санстейн возглавлял до 21 августа 2012 года.

В августе 2013 года Санстейн вошел в состав комиссии по надзору за АНБ (англ. Review Group on Intelligence and Communications Technology). Кроме него в комиссии еще два бывших работника Белого Дома: крупейший специалист по контртерроризму и кибервойнам Ричард Алан Кларк и бывший заместитель директора ЦРУ.

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

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

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

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



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

Часть 4. Архитектор Выбора

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

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

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

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

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

Часть 5. Когнитивные Искажения и Пользовательский Опыт

Итак, мы дошли до основного материала статьи.

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

Для структурирования материала я использовал Кодекс когнитивных искажений, категоризированный и структурированный Бастером Бэнсоном в 2016м году (по ссылке выше дизайн Джона Манукяна III). Помимо новой формы презентации искажений, к каждому из них я добавил пример использования в разработке программного обеспечения, а в некоторых случаях- в управлении командой. Были учтены самые современные практики по управлению командами и компаниями (PMP, PMI ACP), а также разработке продукта.

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

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

Итак, как верно заметил Бастер Бенсон, суть изложенных когнитивных искажений в том, чтобы помочь нам решить 4 проблемы:

• Работа с большим объемом данных. Когда много информации;
• Расплывчатость, недостаточность данных. Когда не хватает смысла;
• Недостаточно времени. Когда быстро реагируем;
• Разные приоритеты по информации. Когда запоминаем и вспоминаем.

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

#1 Эвристика доступности [P]
Процесс, при котором человек оценивает частоту или вероятность события по легкости, с которой примеры или случаи приходят на ум, т.е. легче вспоминаются.

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

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

Последний пример это то, что я выбрал тему проектирования ПО и блокчейн технологий для описания эвристики доступности. Первая тема очевидна для меня в силу моей профессии (product manager), вторая же тема просто с легкостью пришла мне на ум, когда я задал себе вопрос: Какое направление в IT было полно хайпа, а потом быстро сошло на нет?.

#4 Эффект знакомства с объектом [P]
Психологический феномен выражения симпатии к объекту только на основании имеющегося знакомства с ним. Чем чаще человек видит кого-то, тем приятнее и привлекательнее ему кажется этот человек.

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

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

#6 Забывание без подсказок [P]
Является неспособностью вспомнить воспоминание из-за отсутствия стимулов или сигналов, которые присутствовали во время кодирования памяти.

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

Приведу простой пример на онлайн тотализаторе, где множество пользователей делают ставки. Очевидно, что средний пользователь как выигрывает, так и проигрывает. В интересах бизнеса правильно будет поддержать такого пользователя в тот сложный момент, когда он все проиграл. Так как в сознании игрока, который пережил серию поражений одни поражения, система может напомнить ему о целом ряде побед по некоему паттерну, оживив в нем всю ту серию хороших воспоминаний, которые он испытал. Это может быть сделано ненавязчиво, сообщением типа Уважаемый %username%, мы просто хотели напомнить вам о невероятно успешной серии ваших побед, продлившейся три дня подряд на играх %game_names%. Навязчиво? Возможно. Изменим сообщение на Вы попали в топ 20% наших игроков, благодаря вашей серии побед в %game_name%!. Уже не так навязчиво, это уже статистика . Конечно, делать это не этично с точки зрения морали. Поэтому букмекерские конторы и казино, работающие под лицензиями Malta Gaming Authority (MGA), Кюрасао и других, заранее соглашаются, что не будут подталкивать игроков к острым азартным действиям. В любом случае, приведенный пример наглядно иллюстрирует как можно извлечь пользу для бизнеса, зная о такой простой ошибке нашего мозга.

#11 Ошибка базового процента [P]
Это ошибка в мышлении, когда сталкиваясь с общей информацией о частоте некоторого события (базовый процент) и специфической информацией об этом событии, человек имеет склонность игнорировать первое и фокусироваться на втором. Например: люди верят показаниям теста, сигнализирующем о наличии редкой болезни, сразу, не принимая во внимание, что редкая болезнь, вообще говоря, редкая. Либо другой пример: страх террористов и полетов на самолете. Суть в том, что наш мозг склонен преувеличивать частный случай в ущерб статистике.

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

Вы собираетесь запустить процесс дефрагментации диска. С вероятностью 99% операция пройдет успешно.

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

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

Когда люди видят 15,800 хвалебных отзывов и 50 крайне негативных отзывов в перемешку с ними, они склонны считать продукт менее ценным, непропорционально тому факту, что негативных отзывов меньше 0.1%.

#13 Эффект юмора [P]
Смешные вещи легче запомнить, чем не юмористические, что может быть объяснено увеличенным временем когнитивной обработки, чтобы понять юмор, или эмоциональным возбуждением, вызванным юмором.

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

Здесь очень важно понять, что речь идет о запоминании юморных вещей, но не о позитивном отношении к ним. Так, если в процессе работы над важным действием (заполнение формы, сохранение данных), пользователь попадает на страницу ошибки (500 (Internal server error), 502 (Bad gateway), 503 (Service unavailable), 504 (Gateway timeout) ), то юмор типа Хо хо! Наши пираты работают над ошибкой и скоро все будет восстановлено! будет не к месту. В этом случае юмор будет замечен, запомнен, и, вероятнее всего, вызовет гнев пользователя так, что это событие запомнится лучше. Если подобное событие произойдет несколько раз за месяц, в соответствии с эвристикой доступности, в следующий раз подумав о качестве нашего продукта пользователь с высокой вероятностью даст негативную оценку. Даже если в 99% случаев приложение справлялось с задачей (ошибка базового процента).

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

#21 Ошибка различения [P]
Это тенденция рассматривать два варианта как более отличительные при оценке их одновременно, чем при оценке их отдельно.

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

#36 Пренебрежение вероятностью [P]
Когнитивное искажение, согласно которому человек склонен к игнорированию малых вероятностей при принятии решений в условиях неопределенности. Небольшие риски обычно либо полностью игнорируются, либо сильно недооцениваются. Континуум между крайностями игнорируется. Как объясняет Рольф Добелли, причина, по которой это происходит, заключается в том, что мы не обладаем интуитивным пониманием риска и поэтому плохо различаем разные угрозы. По сути, чем более серьезна угроза и эмоциональнее тема (напр. Радиоактивность), тем менее обнадеживающим представляется снижение риска.

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

К примеру, зная что наши пользователи игнорируют вероятность полной потери данных, мы можем подтолкнуть их к созданию бэкапов сообщением вида Уважаемый %user_name%, в последний раз вы создавали бэкап ваших данных 571 день назад. Мы настоятельно рекомендуем создать бэкап чтобы избежать риска полной безвозвратной потери ваших данных.. Здесь мы ничего не говорим о вероятности потери. Она могла постоянно быть равной 0.1%, но написав сообщение с призывом к эмоциям (полной безвозвратной потери ваших данных) и конвертируя условные 19 месяцев в 571 день, мы с большей вероятностью добьемся действия пользователя (бэкап системы).

---

Ссылка на полную версию UX CORE (105 примеров использования когнитивных искажений в менеджменте команд и продуктов)

---

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

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

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

Часть 6. Наши дни

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

На данный момент, взглянув на рынок и на требования к продакт менеджерам лучших компаний, можно обнаружить описания и опросники, на которые ответит почти каждый, кто прошел PMI-ACP. По сути, отсутствие четкого понимания роли Product Manager-а приводит к тому, что на них вваливаются обязанности Project Managerов, Scrum Master-ов, и других.

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

Полагаю, с США дела обстоят лучше, т.к. развитие продакт менеджмента идет именно оттуда.

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

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

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

Часть 7. Не только искажения

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

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

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

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

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

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

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

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

Без внимания к деталям, невозможно добиться высокого качества.

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

Часть 8. Эпилог

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

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

Попробую объяснить иначе. Вне зависимости от идеологической составляющей вашей жизни, вашего стиля и публичного образа, вы можете в любой момент записаться на курсы по SCRUM, изучить этот фреймворк, почитать о нескольких других, понять идеи Agile и устроиться работать проект менеджером в какую-то компанию. Вы также можете пройти пару онлайн курсов и подтянуть ваши знания по front-end и back-end программированию, понять принципы работы баз данных, и это займет у вас буквально месяц. Еще за месяц вы можете сами выучить HTML и CSS, поиграть с разметкой, собрать несколько макетов и понять общую идею работы Javascript.

По сути, вы можете месяца за три собрать достаточно знаний для понимания технической составляющей проекта, и этого более чем хватит для начинающего продакт менеджера. Для понимания трендов вы можете скачать самые последние приложения, пройти по списку самых популярных онлайн платформ, зарегистрироваться на producthunt, betalist, techcrunch и всегда быть в курсе происходящего. Новостной информационный пробел легко восполнить регулярно читая Google News и hackernoon.

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

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

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

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

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

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

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

Большое спасибо за проявленный интерес.

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

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

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

Часть 9. Материал, качественно дополняющий эту статью

• Даниел Канеман Думай медленно Решай быстро;
• Николас Нассим Талеб Черный Лебедь;
• Касс Санстейн и Ричард Талер Подталкивание;
• Ричард Дэвидсон Как эмоции управляют мозгом;
• Михай Чиксентмихайи Поток;
• Джим Коллинз От хорошего к великому;
• Jesse James Garrett The Elements of User Experience (2nd Edition);
• William Lidwell Universal Principles of Design;
• James Clear Atomic Habits;
• Erin Meyer The Culture Map;
• Joe Natoli UX Design Fundamentals Udemy Video;
• Joe Natoli UX & Web Design Master Course: Strategy, Design, Development Udemy Video;

Эта статья была написана в период объявленного карантина из-за пандемии коронавируса (COVID-19) в Армении, г. Ереван. Я очень рад, что статья оказалась полезна многим людям, которые успели ознакомиться с разными частями написанного материала в период моей работы над ней.

Оригинал статьи
Английская версия

По любым вопросам и предложениям пишите, буду рад помочь: alexanyanwolf@gmail.com / www.linkedin.com/in/alexanyan / www.facebook.com/AlexanyanWolf

Привет, Хабр! В преддверии 256-го дня года мы решили выяснить, а откуда вообще берутся IT-специалисты (где их очень ждут, мы знаем и так смотрите вакансии). Так мы опросили больше 700 специалистов со всей страны и вот что выяснили.



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

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

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





IT по-прежнему остается сферой труда с доминирующим количеством мужчин лишь 21% опрошенных Ozon специалистов женщины (за год это распределение не изменилось, аналогичные результаты ранее публиковал портал HeadHunter). Средний возраст специалистов 22-28 лет.

В топ-3 популярных специальностей вошли разработка (3 из 4 опрошенных программисты), тестирование (6% опрошенных) и менеджмент проектов (чуть больше 2%), что также подтверждает статистика вакансий на рынке труда в IT.

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

А как вы попали в IT? Расскажите в комментариях. И с наступающим Днем программиста, конечно!)

Компания "Автомакон" системный интегратор, специализирующийся на автоматизации MLB (Medium to Large Business) c помощью 1С, мобильных приложений, чат-ботов, веб-разработки, систем видеоанализа. Мы работаем с крупными ритейлерами, которые в последнее время стали активно развивать онлайн и доставку. Из-за этого количество задач по автоматизации значительно выросло. Тем не менее, внутри Автомакона ничего не изменилось, и мы смогли сохранить качество во время пандемии почти с 200 сотрудниками на удаленке.

Как мы этого добились?

За время существования компании выработались шесть принципов, которые делают ее деятельность эффективной:

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

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

Сегодня "Автомакон" является успешной IT-компанией. Но так было не всегда.

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

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

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

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

Как и любой стартап мы столкнулись с определенными проблемами. С одной стороны у нас было преимущество в виде сильной команды специалистов, с другой полное отсутствие клиентов. Чтобы переломить ситуацию, мы решили снизить цены и поискать разработчиков в регионах. Это казалось логичным: на тот момент разница в зарплате по сравнению с Москвой была примерно один к трем.

Баланс между поддержкой и контролем

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


Белочка ждет еду от разработчика 1С

Поэтому когда мы перешли на удаленную работу, то разработали свою систему контроля Метеор, ядро на 1С. За годы работы она менялась вместе с бизнесом.

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

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

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

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

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

Самоуправление в компании: миф или реальность?

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

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

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

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

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

Скучная работа во франчайзи, выработка и отсутствие перспектив

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

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

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

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

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

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

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

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

Крупные клиенты и эффективность внутри команды

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

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

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

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

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


Один из корпоративов нашей команды

Еще больше экспертизы и сильных сотрудников

На протяжении долгого времени мы искали универсальную систему оценки новых сотрудников. В итоге наш опыт вылился в 3 правила:

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

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

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

Является ли удаленка лучшим решением для IT?

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

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

Если вас интересует работа в нашей компании, вот тут можно посмотреть полный перечень вакансий hh.ru / наш карьерный сайт.

Будем рады ответить на ваши вопросы!