Про удалённую работу

Обычно такой вопрос не предполагает, что ответ может быть правильным или неправильным. Но 16 марта 2020 года всё не совсем обычно. Сейчас первый вариант ответа — «дома» — мне кажется наиболее разумным и адекватным. Вне зависимости от того, в какой стране вы находитесь. Вне зависимости от того, считаете ли вы себя в группе риска или нет.

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

Наверняка все уже читали ту самую статью (https://medium.com/@tomaspueyo/coronavirus-act-today-or-people-will-die-f4d3d9cd99ca) (или её перевод на русский (https://habr.com/ru/post/491974/)) о том, почему мер, которые мы принимаем сегодня для сдерживания коронавируса, всё ещё недостаточно.

Когда в начале февраля писал пост про удалённую работу (http://t.me/desprod/524), совершенно не ожидал, что мне так быстро представится случай это всё попробовать.

Вот мои (очень наивные) открытия после первых полутора недель дома:
- Чтобы организовать рабочий день, теперь нужно больше дисциплины. Приходится явно блокировать в календаре время не только на встречи, но и на сфокусированную работу. Оказалось, что работа дома очень незаметно стремится заполнять собой всё свободное время. И хотя мне никогда не была близка идея разделять работу и жизнь, всё же жить одной только работой тоже не клёво.
- Звонить человеку напрямую в Слаке (Телеграме) — быстрее и проще, чем создавать встречу, делиться ссылкой на встречу, потом эту ссылку открывать отдельно и т. д. И почему мы так раньше не делали? Ну и не надо расшаривать экран — лучше делиться ссылкой на то, что обсуждаем (дизайн в Фигме, документ, доску в Миро и т. д.).
- Созваниваться с коллегами по видеосвязи, чтобы вместе пообедать или попить кофе оказалось очень прикольно. Хотя и звучит как безумие и постмодернизм. Здорово недооценивал, как много мы в офисе болтаем не про работу и как много этого теряется при переходе на удалёнку.
- Надо стараться выходить из дома каждый день! (Если вы не на полном карантине, конечно.) Социальная изоляция не означает, что нужно обязательно сидеть в четырёх стенах. Можно и нужно прогуляться в парке или выйти на пробежку.

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

Денис Бесков написал о Customer Development (в том виде, в котором подход разработал Стив Бланк).

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

  1. Поиск клиентов. Разработка и проверка гипотез о своих клиентах и их проблемах.
  2. Верификация. Проверка, что клиенты готовы платить за избавление от найденых проблем и что команда способна предложить решение.
  3. Масштабирование.
  4. Построение компании.

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

Product-market fit — ситуация, когда нашлась значимая проблема, за избавление от которой клиент готов платить, и есть решение, как это сделать. После этого решение можно масштабировать.

Если появилась идея продукта:

  1. Предварительно оцените объём рынка. Он должен быть достаточно большим для будущей компании.
  2. Сформируйте гипотезы о целевой аудитории продукта, в ходе какой деятельности у людей возникают проблемы, которые может решить продукт, что это за проблемы.
  3. Проведите глубинные интервью с представителями целевой аудитории, чтобы подтвердить гипотезы.
  4. По результатам интервью уточните гипотезы.
  5. Проведите количественные исследования, чтобы уточнить объём рынка для каждого сочетания проблемы и сегмента целевой аудитории.
  6. Выберите проблему с самым большим рынком.
  7. Создайте ценностное предложение и проверьте его «решенческим интервью» и последующей продажей.
  8. Создайте решение, с помощью которого вы в ручном или полуавтоматическом режиме сдержите данное клиенту обещание. На этом шаге оказание услуги может быть нерентабельным, это нормально.
  9. Окажите некоторый объём услуг в ручном режиме, чтобы проверить, получается ли сделать клиентов довольными, и заодно узнать о сложностях и подводных камнях.
  10. Если клиенты недовольны, ищите другие решения. Если попробовали все возможные решения, возвращайтесь к ценностному предложению и выбору проблемы.
  11. Если клиенты довольны, проанализируйте алгоритм выполнения услуги и определите, что можно автоматизировать.
  12. Оцените затраты на оказание услуги с учётом будущей автоматизации и стоимость привлечения клиентов в разных рекламных каналах. Поймите, получается ли зарабатывать на отдельной услуге. Это сейчас называют юнит-экономикой.
  13. Если экономика не сходится, ищите способ изменить проблемный показатель. Если не получается, пересматривайте решение или возвращайтесь на более ранние этапы.
  14. Если экономика сходится, можно разрабатывать первую версию продукта и далее переходить к построению компании.

На основе Customer Development Эрик Рис придумал Lean Startup — упрощённый подход к созданию стартапов.

С вялым заказчиком каши не сваришь

Иногда пишу зарисовки из проектной деятельности. Вот и сегодня такая зарисовка.

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

Если вам говорят: "С вами будет работать Ира, она в курсе всех процессов, а если надо – будет привлекать ещё кого-то!", то есть повод насторожиться. У заказчика должна быть команда, в которой Ира руководитель проекта, тогда норм.

Из жизни. На заре моего проектного менеджмента (в 2008-2009 году) у меня был проект внедрения системы автоматизации в транспортно-логистической компании. 

Большой проект, большое ТЗ. И один человек на стороне заказчика, который "активно" занимается проектом.

Этот один человек всегда загружен (работу же работать надо), поэтому обратная связь по релизам/вопросам идёт с задержками.

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

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

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

Заказчика в тонусе держать надо, а то на шею сядете и соскользнёте с неё очень быстро.

Гигиена здорового коллектива

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

Необходимы процедуры, которые будут поддерживать здоровье коллектива:

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

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

Спрашивали про точки развития для дизайнера.

Спрашивали про точки развития для дизайнера.

Точек роста для дизайнера четыре:

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

— Творческое развитие. Создание индивидуальной творческой траектории независимости и автономной работы. Частный проект в котором дизайнер один на один со своей личной задачей. Создание личного проекта с осознанными и глубокими мотивами самореализации.

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

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

Вопрос: есть команда из трёх человек

Вопрос: есть команда из трёх человек: сильный разработчик, который делает быстро, но поверхностно; есть слабый разработчик, который делает медленно, но работающий код (и часто переделывает за сильным) и есть тимлид/пм (я), который не сильно разбирается в коде. Сильный буллит слабого, что тот не разбирается и вообще плохой программист. Что делать?

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

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

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