Управление проектами *

Про нетерпимость к неопределённости

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

Но в разговорах между собой мы вечно утыкались в непонимание:

— Вот план на квартал. Три фичи.

— Не, ты скажи, какая когда будет.

— Вот относительные приоритеты, делать будем в таком порядке. Но точные даты будут только после ресёрча. Не страшно: по зависимостям никого не держим; по метрикам - всё просчитано, неделя туда или сюда именно здесь погоды не сделает.

— Не, ну даты-то какие?

— Точные даты я тебе могу назвать, но они ж из головы будут.

— Пусть так, но пусть будут.

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

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

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

Кому-то это некомфортно - но зато если им эти точки опоры дать, они разгонятся и принесут результат.

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

Российская ИТ‑компания ITGlobal разместила на сайтах с вакансиями объявление о найме в штат экзорциста, которому собирается платить от 130 тыс. рублей в месяц Специалисту придётся изгонять демонов из неэффективных сотрудников. Нужно переехать в Санкт‑Петербург — работа исключительно офисная, удалёнка в условиях не упоминается

30 минут лучше чем 60 (если вы понимаете о чем я)

Вывод в начале, чтобы и тут оптимизировать время!

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

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

Подробнее

Для контекста небольшое наблюдение за собой: раньше я пользовался Google-календарем, в котором по умолчанию встречи создавались на час. Визуализировалось все по умолчанию блоками по часу. Сейчас моим инструментом работы с календарем стал Outlook. В нем по умолчанию день разделен на блоки по 30 минут.

Конечно, это настраивается и в Google-календаре, только раньше я об этом не думал.

Что изменилось?

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

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

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

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

Почему это важно?

Отдельно расскажу, что осталось в моей голове после курса общей психологии по разделу «Внимание». 

Внимание и сосредоточение требует усилия. И эффективное сосредоточение, во время которого вы продуктивны у взрослого человека обычно 45 минут. Мало?

Скорее нет. Например, у детей в разном возрасте это считанные минуты. Кажется, только к 12 или даже позднее эти центры мозга формируются до конца. Отсюда время одного урока - 45 минут. Скажете, что пары в универе длятся 1,5 часа. Да, и это не супер хорошо, кмк. Можно тут почитать разные рассуждения на эту тему (осторожно, Яндекс Кью). Отсюда же берет начало метод Pomadoro (нет, это не те, которые можно кинуть в автора).

Что еще можно прочитать

1. Что такое концентрация внимания и как и для чего её развивать (2022 г).

2. Как «научиться учиться» — улучшаем внимательность (2019 г).

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

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

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

И тогда я стал задавать прямой вопрос - а какой стиль работы в целом ближе? На развитие или на получение результата здесь и сейчас?

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

Людей с майндсетом Run:

• драйвит быстрый результат;

• не беспокоит необходимость возвращаться к одному и тому же предмету несколько раз;

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

Типичные Run-овые задачи - это поддержание страниц в актуальном состоянии, поддержка, запуск экспериментов.

А майндсет Change:

• драйвит картина чего-то большого и красивого - но впереди;

• не любит возвращаться к уже сделанному, предпочтёт более сложную реализацию на перспективу;

• предпочтёт потратить побольше времени на подготовку.

Тут задачи уже другие: выстраивание процессов, инфраструктурные проекты, доделывание продукта после MVP.

Разумеется, шкала тут не дискретная, но всё же совсем универсалов я практически не видел - все явно склонялись либо к одному, либо к другому концу.

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

30 000 ₽ на тестирование облачных сервисов Selectel

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

Хотите сократить расходы на инфраструктуру в три раза, как Гардиум, и привыкли все проверять заранее? Мы поддерживаем ответственный подход к работе.

В Selectel вы можете получить до 30 000 бонусов на тестирование облачных сервисов в течение месяца. Так вы изучите на практике подходящие для ваших целей решения.

Как воспользоваться грантом

• Зарегистрируйтесь в панели управления;

• Опишите в тикете, какие сервисы в облаке хотите протестировать;

• Проконсультируйтесь с нашим менеджером;

• Получите промокод на необходимую сумму бонусов и активируйте его в течение 7 дней;

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

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

Об эталонном аджайле и мультикультурности

Работали мы как-то на проекте с немцами: огромный концерн, куча юрлиц. Помогали им визуализировать данные из БД на несколько миллиардов записей. И оказалось, что немцы и вправду очень педантичны в работе. Они строго следовали всем правилам и инструкциям. 

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

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

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

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

• Вывод 1. Не стоит слепо следовать даже самым популярным практикам. Подходите ко всему с умом, а не формально. Создавайте свой уникальный фреймворк, который подходит именно вашей ситуации и вашей команде.

• Вывод 2. Для успеха нужны опыт, здравый смысл, смелость сказать начальству «нет» и понимание лучших практик, чтобы собирать свою реальность из правильных «кирпичиков». И, конечно, человеколюбие.

• Вывод 3. Созвоны — зло, если их у команды разработки больше двух в день. Они убивают продуктивность у всех.

Больше об управлении проектами рассказываем в отдельном телеграм-канале.

У каждого своё одеяло

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

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

Но стоит кому-то вмешаться и "потянуть одеяло" — начинается хаос. Дизайнер лезет к разработчику, маркетолог пытается учить логиста, а руководитель знает всё лучше всех. В итоге — никакого комфорта.

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

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

Команда из девяти сотрудников Nokia в 2007 году выступила с внутренней презентацией, на которой объявила, что представленный первый iPhone от Apple может изменить стандарты индустрии и станет лидером рынка.

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

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

Культура и практика написания MoM (minutes of meeting)

Короткий пост о том, что это такое, зачем (и для чего) и, конечно, как.

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

Что такое MoM (Minutes of meeting)? 🤨

Короткие, тезисные записи ключевых мыслей по результату встречи.

Зачем MoM?

• Юридическая значимость, если использовать email для фиксации позиций и решений (возможно, в мессенджерах тоже, но в email я уверен)

• Синхронизация представления о результатах встречи

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

Как MoM?

• Идеально - сразу после встречи (чтобы не забылось)

• Путь написания письма (email). Вспоминаем пункт про юридическую значимость

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

  • Кто был на встрече (участники)

  • Что обсуждали (ключевая тема, ответвления) 1±2

  • Что решили (ведь зачем-то собирались?)1±2

  • Задачи, которые появились на встрече. Кто исполнитель и, конечно, дедлайны по ним. Тут ограничений нет.

  • Следующая встреча - требуется ли, дата и время

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

Что еще можно почитать на эту тему:

• Учимся проводить совещания (2008 г)

• MoM: Как? Зачем? Почему? (2024 г)

Не делегируете, потому что хотите быть не заменимым?

И это действительно часто оказывается правдой.

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

Здесь важно перестроить свою роль и осознать: вы остаетесь важным звеном в компании, но уже в другом качестве. И чтобы сделать рывок:

• Перестаньте заниматься микроменеджментом

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

• Найдите время для стратегии

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

• Обучайте сотрудников приносить решения, а не вопросы

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

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

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

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

Если вы решили, что с нового года надо начать читать книги

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

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

О книге в 18 словах

У нас есть 2 типа мышления — быстрое (интуитивное) и медленное (аналитическое) — они оба влияют на наше поведение и принятие решений. 

Полезность чтения для продакта (и не только для него) 

➛ Поймёте, почему вы и пользователи вашего продукта принимаете те или иные решения.

➛ У вас появятся новые нейронные связи, а это почти равно новым идеям.

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

Прямо сейчас это единственная книга, которую я могу рекомендовать с уверенностью — но имейте в виду, что я совсем не чтец, а только жнец и на дуде игрец.

Зачем вы читаете? Расскажите :)

Система управления проектами для удаленных команд Virex теперь доступна!

Коммуникация, задачи, аналитика, гибкость — всё это про Virex.

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

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

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

Встроенные чаты для каждого проекта. Общайтесь со своей командой прямо в Virex.

Заходите в Virex прямо сейчас!

https://app.virex.studio

Полезные советы от разработчика OpenSearch Даниила Дубровкина из AWS.

Вы смотрели The IT Crowd? Это уморительный британский телевизионный ситком примерно 2006 года, в котором группа ИТ‑гениев работала в отделе технической поддержки Reynholm Industries в Лондоне. Один из характерных смешных моментов заключается в том, что каждый раз, когда звонил телефон, Рой брал трубку и, не дожидаясь ответа, спрашивал: «Вы его выключили и снова включили?», а затем вешал трубку. Я часто чувствую себя Роем, когда общаюсь с пользователями, сообщающими об ошибках в проектах с открытым исходным кодом, которые я поддерживаю.

Вот мой структурированный подход к любым ошибкам (багам, проблемам), о которых сообщают в моих проектах с открытым исходным кодом:

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

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

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

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

5. Не делайте ничего другого. Не можете получить никакого участия в устранении ошибки от человека, сообщившего о ней? Оставьте ошибку открытой. Кто‑то другой её подхватит.

tl;dr Не исправляйте ошибку! У здорового проекта с открытым исходным кодом будет много вовлечённых участников, особенно когда дело касается ошибок. Это один из самых простых плодов, которые вы можете собрать как сопровождающий. Тем не менее, иногда я просто хочу исправить ошибку сам, потому что это так интересно.

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

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

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

Закон Хайрама — чем больше у API пользователей, тем сильнее они полагаются на незадокументированные особенности, превращая их в «обязательные» функции. Из‑за этого любые изменения становятся сложными, ведь легко сломать что‑то для тех, кто уже привык к старым фишкам.

Закон Конвея — структура программ часто повторяет организационную структуру команды, которая её создала. Если слепо следовать границам в команде, софт получится неоптимизированным.

Закон Линуса — база опенсора. Чем больше людей проверяют код, тем больше шансов найти ошибку.

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

Закон Кернигана — код всегда должен быть простым и понятным. Сложный код всегда становится неподъёмным в отладке и сопровождении — это только вопрос времени.

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

Закон Парето — усилия должны быть избирательными. Чтобы 20% усилий приносили 80% результатов, сначала нужно понять, куда прикладывать эти усилия. Качество всегда перевешивает количество, а результат важнее времени затраченного на задачу.

Почти универсальные проектные принципы или Как перестать зависеть от методологий — Егор Сизяков / Ural Digital Weekend 2024

1. Что такое NUPP и зачем они нужны?

2. А конкретнее? Разбираем NUPP 1−6.

3. Как их внедрить на практике?

Ссылка на запись доклада в ВКонтакте.

Ссылка на презентацию: https://goo.su/SBXix

Как создать ценность там, где про неё редко спрашивают — Алексей Мезенцев / Ural Digital Weekend 2024

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

Ссылка на видео в ВКонтакте.

Ссылка на презентацию: https://goo.su/L1g8Vmv

Как добиться взаимопонимания между клиентами, менеджерами и программистами — Григорий Кирейчук / Ural Digital Weekend 2024

— Разговоры на одном языке, как мы этого добиваемся

— Визуальные схемы: превращаем сложное в понятное

— Как мы экономим время команды и заказчика на погружение в проект

— Промежуточные презентации и почему они важны

Ссылка на запись доклада в ВКонтакте.

Ссылка на презентацию: https://goo.su/hgU2IPF

Эффективность Шредингера: метрики работы команды разработки, поиск и устранение узких мест в процессах — Полина Таран / Ural Digital Weekend 2024

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

Ссылка на видео в ВКонтакте.

Ссылка на презентацию: https://goo.su/Tuyca

Масштабирование под давлением — возможность или вызов?

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

• как обеспечить рост монетизации по модели cost-per-action;

• как масштабировать CPA от MVP до 1млн RPM;

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

Переходите по ссылке, чтобы ничего не упустить.

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