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

Индустрия — это экосистема. Большинство проектов реализуется несколькими компаниями, командами и отдельными специалистами в симбиозе. Клиенты обращаются в компанию, которая нанимает себе в помощь продакшн для разработки и т. п.

Типовая производительность в час — полная профанация. Точная предварительная оценка проекта невозможна в принципе. Всё зависит от конкретного проекта и конкретного специалиста.

Типы проектов:
1. Мозги — решение ранее неизвестных задач. Проект похож на исследовательскую работу и привлечённые специалисты должны быть опытными профессионалами, имеющими сложившийся подход к поиску нестандартных решений.
2. Седина — внедрение проверенных отраслевых или технологических наработок, которыми обладает компания-подрядчик. Например, программа лояльности в розничной сети. Компании, работающие над такими проектами, специализируются на определённых отраслях.
3. Процедуры — типовые задачи, с которыми могут справиться различные специалисты с заданной квалификацией. Например, разработка программных компонентов по детальной спецификации в уже определённой технологической среде.

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

Типы исполнителей:
1. Фармацевт (самый распространённый) — классический аутсорсинг. Клиент приходит со сформулированной задачей, исполнитель через некоторое время выдаёт результат.
2. Сиделка — агентства. Исполнитель интенсивно общается с клиентом, работа выстроена вокруг долговременных целей клиента.
3. Нейрохирург — системные интеграторы и технологические исследовательские центры. Похоже на фармацевта, но часто сутью задачи является выяснение, в чём именно заключается проблема клиента и поиск её решения. У задач — преимущественно технологический характер.
4. Психотерапевт — продюсеры ИТ-проектов. Клиент обозначает проблемы в бизнесе или возможные точки развития, а исполнитель помогает подобрать наиболее удачный способ решения.

Бизнес-модели:
1. Ресурсная — продажа труда специалистов по часам или проектам. Компания должна продать как можно больше ресурсов, что неизбежно приводит к типу проектов «процедуры» и формату работы «фармацевт» или «сиделка». Клиент всегда может сменить подрядчика. Подрядчики конкурируют ценой, уровнем специалистов и качеством менеджмента.
2. Продажа уникальных знаний — цена услуги формируется не себестоимостью, а ценностью для клиентского бизнеса.

«Любая компания с регулярными расходами пытается добиться регулярного поступления оплат от клиентов. А они возможны в случае, когда команда специалистов как можно дольше работает над одним и тем же проектом, и её состав не меняется. Именно с этим связана любовь компаний-разработчиков к скраму, т. к. у проекта нет разных по стоимости этапов, команда максимально однородна и специалисты взаимозаменяемы. Работа над проектом разбита на равные отрезки времени — спринты, за которые удобно выставлять регулярные счета. Дело как обычно в деньгах, а вовсе не в каком-то волшебном качестве скрама».

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

https://mityakin.ru/paranoid-method-book-1

Метод гипотез в решении технических задач

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

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

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

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

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

Периодически обновлять фреймворк

У нас в ГдеМатериале есть хорошая практика — мы периодически проверяем актуальность зависимостей. Я говорю не о мелких обновлениях и не о фиксах безопасности (они давно автоматизированы), а об обновлении мажорных версий библиотек, скажем Django с 1.11 до 2.0.

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

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

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

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

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

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

Немного матана! Совсем недавно, на интервью я столкнулся с интересным вопросом: «Сколько нужно протестировать пользователей, чтобы обеспечить достаточную для большинства случаев точность исследования?»

И казалось бы, ответ довольно очевидный: мол Нильсен говорит 5. Но почему 5? Откуда это магическое число? Без математики не обошлось.

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

Если прорезюмировать, то можно сказать, что Нильсен не был не прав 🙂 Однако стоит приводить полный ответ:

—————————————————————————

Если во время тестирования эксперименты будут независимыми, а выборка по крайней мере квазислучайной, то мы можем предположить, что при тестировании 5 пользователей мы обнаружим 85% ошибок, с которыми сталкиваются не менее 31% пользователей.

—————————————————————————

Последняя часть, вообще интересная, не правда-ли? ) «Не менее 31% пользователей», то есть в самом неудачном случае 59% пользующихся так и не столкнуться с проблемами. Но это не слишком страшно.

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

http://bit.ly/2UqfhOs

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

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

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

Второе, что мы попробовали сделать — зарегистрироваться в качестве специалиста.

И у нас не получилось.

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

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

Но и это еще не все!

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

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

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

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

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

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

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

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

Что-то все начали обсуждать выгорание

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

— Работали несколько (!) лет в напряженном режиме.
— Регулярно работали 9 и более часов в день и в выходные.
— Вписались в несколько проектов: 2, 3, 4 и более.
— Совмещали работу с интенсивными спортивными тренировками.
— Добавили изучение языков или другое системное образование.
— Решили строить персональный бренд: много выступали и писали тексты по ночам.
— Решили, что нужно вставать в 6-7 утра и сразу в бой.
— Было много командировок с ломаным графиком.
— Злоупотребляете кофе или другими стимуляторами для поддержки работоспособности.
— Несколько раз сталкивались с головными болями после переработок.
— 2 и более лет не брали отпуск.

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

Решение вытекает из понимания сути проблемы (усталость): остановиться и признать тот факт, что вы не биоробот, а просто человек. Избавиться от обязательств и проектов, хорошенько отдохнуть, перестроить свой график и подходы к работе ... затем вернуться к работе. Если через два дня вы застали себя в исходном состоянии, ДЕЙСТВИТЕЛЬНО перестроить график и подходы.

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

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

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

И да, кто-то должен был это сказать: люди 35+ лет с опытом работы 15+ лет нервно подергиваются когда слышат разговоры о выгорании от совсем молодых ребят.