Alexcouncil⚡

🐎 #смешнобольно

Закон Брукса⏰ Пошел учиться на системное мышление наконец-то. Откладывал эту часть 2 года и вот оно наконец-то случилось. Кайфую. Сейчас копаю основные законы, которые работают в различных системах, один из них называется закон Брукса. Встречал его кучу раз на практике, но не знал, что так называется. Суть Добавляя больше людей на поздних стадиях проекта, чтобы спасти сроки, вы еще сильнее в них не попадете. Фредерик Брукс сформулировал этот закон еще в 1975 году в своей культовой книге «Мифический человеко-месяц». Казалось бы, математика начальной школы: если 2 копают яму за 4 часа, то 4 выкопают за 2. Почему в IT это не работает? Потому что Проект — это не просто сумма людей, это система связей. Когда мы добавляем в нее новые элементы на поздних этапах, происходит следующее: 1.Коллапс коммуникации Количество связей в команде растет не линейно, а экспоненциально по формуле N(N-1)/2 Команда из 5 человек — это 10 каналов связи. Команда из 10 человек — уже 45. Больше людей = больше митингов, согласований, конфликтов при слиянии кода и потери контекста. 2. Стоимость онбординга Новый человек на проекте не начнет приносить пользу в первые дни. Его нужно ввести в курс дела, показать архитектуру, выдать доступы. Кто это делает? Ваши самые опытные сеньоры, которые вместо спасения релиза теперь работают няньками. Скорость команды в моменте упадет. 3.Неделимость задач Это про «Девять женщин, которые не смогут выносить ребенка за один месяц»*. Некоторые задачи строго последовательны. Вы не можете ускорить процесс компиляции, тестирование сложного флоу или продумывание архитектуры просто посадив за это больше людей. Пара примеров закона Брукса Разработка. Делаете сложную интеграцию с платежным шлюзом, дедлайн через неделю, не успеваете. Если добавите в команду еще одного бэкендера, текущему лиду придется потратить 3 дня на то, чтобы объяснить ему легаси и бизнес-логику. В итоге потеряете время лида и не получите выхлопа от новичка. QA. Перед релизом накопилась гора багов. Перекидываете на проект трех тестировщиков из соседней команды. Они не знают ваш продукт, заводят дубликаты багов, дергают разработчиков доп.вопросами, парализуя процесс фикса критов. Мой пример Помню как тащили гигантский проект и вышли на финал, где последние 3 месяца нужно было просто фигачить и дотаскивать. Тревожность менеджмента повышалась, все хотели заглянуть глубже в команду. Мы понимали, что если не защитить ребят от митингов и разговоров точно вылетим за сроки. В итоге, взяли удар на себя по паре раз в неделю устраивали чеки, синки и давали актуальный статус. Команда работала, никто не отвлекал, затащили💪 Нюансы закона Закон Брукса часто понимают слишком буквально и совершают ошибки. Моменты, о которых важно помнить: 1. Закон применим к *отстающим* проектам на *поздних* стадиях. Если вы только стартовали или находитесь на раннем этапе, масштабирование команды работает отлично. 2. Исключение закона - идеально изолированные задачи. Если вы можете выделить кусок работы, который вообще не пересекается с основным функционалом (например, ручная разметка датасета, перевод текстов интерфейса на другой язык), добавление людей реально ускорит процесс. 3. Ловушка «никогда не нанимай». Иногда добавить людей в горящий проект *нужно*. Да, краткосрочно сроки сдвинутся еще сильнее, и вы должны открыто сказать об этом стейкхолдерам. Но стратегически, если проект долгий, через пару месяцев эти новички втянутся и вытащат вас из ямы. Главное — не ждать от них чуда «здесь и сейчас». Итого Думайте, когда добавляете людей на поздних этапах проектах. Точно ли оно того стоит! P.S. Напишите в комментариях ловили ли на себе закон Брукса? #рекомендуетсяизучить

Напишите в комментариях навык/знание которое нужно качать в ближайшие 5 лет, чтобы быть актуальным рынку. #опрос

😈 #смешнобольно

Кастомный фичеринг Катите какую-то новую штуку в продукте, подумайте как о ней узнает пользователь. Но не все фичи нужно сопровождать попапами, всплывахами и рассылками. Одна из таких в Яндекс Навигаторе попалась мне на днях. Ребята подсвечивают куда смотрят камеры. Синее поле - если ты в допустимом скоростном режиме и красное, если превышаешь. Узнал об этой функции нативно, стоял на светофоре, смотрю какое-то поле показывают. Думаю о как круто, вау эффект и лояльность продукту. То есть, мне, как водителю, не нужно дополнительно объяснять, что это и зачем. Очевидная функциональность без доп.промо, кайф. Выбор делать фичеринг или нет решается через простые ux тесты на небольших выборках. Дал целевым респондентам задачку с новой функцией, посмотрел справляются или нет, принял решение. Хорошо же❤️ #юиксюайное

За кулисами страт.сессий🎭 Сейчас в ИТ-корпорациях в самом разгаре циклы стратегического планирования. Тайминг по рынку классический: - Май-июнь — сборка стратегии - Июль — защита у акционеров - Август-сентябрь — бюджетирование Под сборку стратегии обычно устраивают страт.сессии на 1–3 дня, где заявленная цель — вытащить менеджмент из рутины, сгенерить идеи и упаковать их в стройный план. Но это далеко не полный комплект. Я прошел через десятки таких мероприятий в разных составах. Помимо базовых задач (набросать скелет стратегии, покачать команду друг об друга), начал замечать скрытые эффекты, которые мало кто использует потом. По сути, страт.сессия — это стресс-тест и диагностика команды по трем параметрам. Давайте про каждый. 1. Краш-тест социальных связей Способны ли люди вообще работать друг с другом в замкнутом пространстве? В офисе можно спрятаться за долгими переписками, но здесь время жестко ограничено. Нужно договариваться здесь и сейчас. Если спроецировать скорость взаимодействия этой группы на обычную опер.деятельность - сразу видно, где система будет буксовать. 2. Проверка на масштаб мышления Может ли команда выдавать качественно другие решения? Не «давайте делать то же самое на 10% быстрее», а системно менять: - рынок - ценность - дистрибуцию - монетизацию. На сессиях всегда виден контраст: кто-то челленджит и пушит амбиции, а кто-то отмалчивается в зоне комфорта. Еще один индикатор силы команды. 3. Уровень энергии Горят ли глаза? Слушают ли друг друга? Готовы ли объединяться, чтобы защищать идею? Эти сигналы показывают реальный заряд «батарейки». Если на страт.сессии все вялые и ждут вечера, а дискуссия утопает в телефонных экранах, на этапе реализации чуда точно не случится. А дальше что Дальше используйте всю эту фактуру (связи, амбиции, энергию) для следующих забегов. Качайте команду, развивайте компетенции и направляйте в нужное русло. Главное — смотреть шире флипчартов и стикеров, а там глядишь то, что собрали на страт.сессии и в реальность превратится🔥 #продуктовыйпуть.

- У нас data-driven культура. - А почему тогда решение уже принято? - Данные просто сейчас подгружаются. #смешнобольно

Метод Дельфи Сдуваю пыль со старого инструмента брейншторма. Боль: - вам нужно поштурмить решение какой-то задачки - зовете толпу из разных экспертов - вдруг самый громкий начинает перекрикивать остальных и топить за свое - часть к нему подключается, часть уходит в себя и телефоны На выходе однополярное мнение без альтернатив. Чтобы такого избегать можно использовать метод Дельфи. Инструмент изобрели еще в 50х годах прошлого столетия для оценки влияния технологий на методы ведения войны, но дальше он разошелся в массы как инструмент генерации идей. Как это работает Вот так: 1. Собираете команду. 2. Рассказываете про цель и технику проведения встречи. 3. Обозначаете проблему так, чтобы с ее формулировкой были согласны все участники. 4. Дальше просите анонимно записать все варианты решения на стикеры (один стикер — одно решение). 5. Собираете все полученные стикеры, группируете похожие идеи и составляете общий список. 6. Уточняете, нужно ли что-то дополнить. 7. Просите каждого проголосовать за лучшие решения. Квота 1 участник не больше 3 голосов, за свой нельзя голосовать. 8. Дальше считаем голоса, выбираем топ решения из списка, берем в работу. В итоге уходит сила "авторитета", каждый может занести идею, дальше сопричастность и вовлеченность. Техника работает от 7-30 человек за счет статистической достоверности и выборки. Если будет меньше народа, то никакой Дельфи вам не нужен, итак, договоритесь, а на бОльших группах будете доп.время тратить на организацию, не получая доп.эффектов. Проводить подобные штурмы можно хоть оффлайн (побольше вовлеченности), хоть онлайн. Где сам использую Дельфи В ретро, когда команда закидывает то, что было хорошо, плохо, решения для плохо с голосовалкой. Работает на ура, стильно, модно, молодежно. На стратегических сессиях и прочих штурмах. То же самое - кайф. Структурно, последовательно, без криков и брызгания слюной. На выходе у тебя приоритезированный списочек где поучаствовали все, неуслышанных нет. Важно (без сахара) Состав рабочей группы - ключ к качественному штурму. Метод Дельфи это всего лишь инструмент, важно кто с его помощью генерит решение. Подбирайте участников под задачу, учитывайте уровень и область экспертизы, которые необходимы. Рекомендации: - группа составляется из кросс функций, чтобы вытащить правду посередине - если берете топов, то они должны быть вовлечены, просто посидеть в экране не пойдет - не частите с брейнштормами на одних и тех же людях, выгорят, устанут Ну и завершая Скажу, что обсуждения с генерацией идей - это настолько частый сценарий в работе менеджера чего-либо, что хочется его оптимизировать. История - давай возьмем самых авторитетных и пусть они штурмят любые задачи звучит, конечно, авторитетно, но неэффективно. Берегите время. #инструментыпродакта

A/B на Gemini Попал в эксперимент на гугловской Gemini. Всегда нравился их утилитарный минимализм - просто и открыто спрашивают: "Это или вот это?". Выбираешь и чувствуешь какую-то сопричастность что ли. Приятно. Вообще месяц назад словил aha момент, когда в длинную строку поиска хрома не задумываясь начал вбивать длинный запрос. Не как раньше "пластиковое окно москва", а прямо предложение с глаголом "собери мне подборку, вытащи плюсы и минусы...". Паттерн поменялся. #рекомендуетсяизучить

Когда попросили подхватить задачку ненадолго и обещали помочь #смешноибольно