Задать вопросы можно мне в личку: @r2d2_e2e4

Маркетинг освобождённый

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

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

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

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

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

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

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

Вам нравится, когда у маркетинга и продаж развязаны руки?

https://www.youtube.com/watch?v=5O7gaOLwxGY

Канал коллеги инженера, который пишет по теме девопс полезные заметки и просто всё, что видит https://t.me/DOFH_ru

О том, кого нанимать, или "мы снова в игре!"

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

В этот момент главные герои спокойно достают домашнюю заготовку "кузькина мать" и ею взрывают ситуацию. Буквально. Звучит фраза, которая достойна стать гимном любых героев, выбравшихся из болота. Они СМОГЛИ сказать: "Мы снова в игре!!!"

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

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

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

Нанимайте правильно! :) Помните про тот пляж и помните про деление на "паровозы" и "пассажиров".

https://www.youtube.com/watch?v=oGEi0B06ClM

Про паровозы и пассажиров

В проекте (поезде) есть те, кто толкают поезд вперёд, - паровозы, и те, кто кто просто пьёт чай и жуёт печеньки - пассажиры. Причём, эти люди присутствуют и в управленческой команде и в технической.

Пассажиров (тех, кто пьёт чай) очень легко узнать по их позиции, - именно от них вы постоянно слышите первую половину их правила: «не навреди!». Полностью же их принцип звучит так: «раз я не умею ничего делать, то займусь тем, что просто не буду вредить!» Как правило, они не мешают и в этом их главная функция.

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

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

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

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

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

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

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

Оно и понятно, - на переправе коней не меняют! Формируйте основной состав команды заранее, - до возникновения сложностей с проектом и наступления дедлайнов :)

https://www.youtube.com/watch?v=sOrGv26Yla0

Выхода нет

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

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

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

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

2) Идея залатать отличная, но только нам сцыкотно. Поэтому давайте мы залатаем, но не так чтобы все сразу, а, например, 1/3 дыры. Вы в процессе как раз и в тонкостях разберетесь, и к запахам нашим попривыкните, и даже с социальной стороны хорошо - нам не придется увольнять держателей швабр.

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

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

https://www.facebook.com/photo.php?fbid=1715860621807246

MVP как инструмент эволюции

Природа развивается эволюционно, отметая бесчисленные варианты неудачных гипотез. Спросим природу? Сколько будет 2+2? Она радостно начнёт выкрикивать: 3, 7, 13, 4, 22, 49, 143.... Но сработает только один.

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

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

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

В технической разработке всё ровно также.

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

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

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

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

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

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

MVP - это вопрос рынку: готов ли он? нравится ли это ему? хочет ли он это? несёт ли это ему ценность?

https://www.youtube.com/watch?v=ZDwyI4gaE7k

Оценка проектов

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

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

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

* Девопсы: секретное оружие - выходит строит проект без своих девопсов теперь можно смело называть попыткой суицида. По сути наличие девопсов сокращает сроки вывода релизов и починки аварий на порядок.

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

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

ВОПРОСЫ:

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

Дело в том, что MVP представляет ценность не только с технической точки зрения, но ещё и с точки зрения бизнеса. Это УЖЕ работает и это УЖЕ принесло первый рубль. Но только после получения этого MVP вообще реально говорить о каких-либо сроках.

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

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

Если же договорится с бизнесом (продуктоводами) не удаётся на этапе готового mvp (хотя повторюсь, mvp - это откопанное золото, радость от которого велика настолько, что танцуют все!), то проблема не в продукте, а в продуктоводах.

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

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

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

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


Мурзин Андрей: Про два часа на исследования, надеюсь, просто пример? Ограничивать время нужно, конечно. Лимит от задачи зависит.

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

https://www.youtube.com/watch?v=Q3unJfSjAPE

Генеалогия реляционных бд

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

Смирнов Алексей @arkenoi рассказал, в чём отличия от типового комплаенс от вводимого GDPR (новые правила обработки персональных данных в Европе для международного IT-рынка)

Типовой комплаенс, вроде pci dss — он в основном про чеклисты. "должно быть так и так"
а в gdpr вообще чеклистов нет, он про процессы
собственно в основном про то, что
a) есть внятное описание какие персональные данные обрабатываются и как
b) эта обработка не избыточна
c) есть отвественный
d) по запросу пользователя ему подробно покажут что про него есть
e) после того как в данных отпала нужда или пользователь попросил их удалить — они удаляются.

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

Всю эту неделю я с удовольствием вёл канал https://twitter.com/backendsecret и сейчас кратко продублирую здесь некоторые твиты.

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

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

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

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

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

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

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

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