R&D команды в IT
В прошлом посте я упомянул R&D команды и получил несколько вопросов на этот счет. Такие вакансии встречаются не часто и многие о них вообще не слышали.
Между тем, я считаю, что R&D команды — это самая "живая" часть Энтерпрайза 😉
Так что же это за зверь такой?
R&D команды разработки есть у крупных компаний, чей основной продукт прочно засел на плато по циклу Гартнера 🤓

Задача R&D команды — это создание решения, под новые гипотезы, с нуля, любыми доступными способами и без гарантии доставки результата.

Специфика R&D команд:
🔹У Вакансии разработчика в R&D команду нет тех.стека
🔹R&D команда - первая на очереди сокращений, когда возникают проблемы
🔹У R&D команды нет четко сформулированных задач
🔹R&D команда не дружит с безопасниками и часто оформляется на отдельное юр.лицо
🔹У R&D команд нет задач на мониторинг, логирование, безопасность. Не звучат слова типа "автоскейлинг, рейт лимит, а/б тест". Нет и крутых CI/CD пайпов (на этом моменте у каждого продуктового разработчика появилось неприятное ощущение)
🔹R&D не отдается на аутсорс и не привлекает разработчиков по аутстафф модели
🔹Руководители R&D команд, любят считать, что у них "как в стартапе", но это не совсем так :)

Специфика R&D разработчиков:
🟣В вакансиях разработчиков в R&D команду, зачастую нет тех стека, потому что разработчик в R&D должен быть готов быстро переключится на нужный
🟣У R&D разработчика, желателен определенный склад ума, который сильно отличается от продуктового
🟣R&D разработчик, зачастую может и самостоятельно (в одного) запускать продукты
🟣R&D разработчика не пугает задача, описанная "мутно"
🟣R&D разработчик не рефлексирует месяцы после того, как его продукт закрыли или отдали в продуктовую разработку (это сложно)
🟣R&D разработчику нравится решать задачи, ответа на которые нет на StackOverflow

Хотели бы быть частью R&D команды?
🔥 - R&D это круто
🦄 - R&D это не серьёзно

Читать полностью…

Продакты не нужны. Часть 1. Ошибочное представление
Решил написать серию постов о проблемах, которые есть в сфере продактов. Думаю, она будет полезна тем, кто когда-либо задумывался «не пойти ли мне в продакты». Так что если у вас есть такие знакомые, коллеги или друзья, то отправляйте им ссылку, возможно им это будет полезно.

Существует две волны продактов:
1️⃣Выросла в корпорациях (чаще из бизнес-аналитиков) и прекрасно представляла, что её ждет
2️⃣Люди, которые не очень понимали кто такой продакт и им продали идею о том, что «продакт — это мини CEO» или ещё круче «предприниматель в найме»
Первые, чувствуют себя на своем месте и почти все они органично выросли из бизнес-аналитиков, постепенно расширяя свою зону ответственности. То есть они всегда были в найме, мыслили, как наемные работники и решали тактические задачи для своей зоны ответственности. После чего доросли до CPO и уже тут начали осваивать новые навыки и иногда даже думать о стратегии компании/продукта. В общем органический рост специалиста, без слома майндсета.
А вот у тех ребят, кому продали идеи о том, что продакт - это предприниматель, но «не на свои» существуют проблемы. Ведь когда они думали о своем деле и не решались на него по разным причинам, они представляли себе, как пойдут накапливать релевантный опыт: «менять рынок», «принимать сложные управленческие решения» и т.д. Но реальность оказалась далека от ожиданий: управление метриками, ответственность за «доменные зоны» и минимальное влияние на бизнес не приближали их к мечте о предпринимательской свободе. Терялся смысл. А смысл - очень важная вещь. Деньги не могут заменить отсутствие смысла.
Далее начинает казаться что это с компанией что-то не то, или с твоей позицией. А возможно просто не дорос ещё. Но все это ведет к потере мотивации и депрессиям, а со сменами компаний, роста опыта и позиции принципиальных изменений не появляется.
Правда в том, что продакт - не предприниматель. И это следует принять тем, кто хочет быть в этой профессии.

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

От предпринимательства в работе продакта - очень мало. И даже это мало, появляется только на уровне CPO.
На ранних стадиях бизнеса или стартапа, почти никогда нет продактов, как думаете, почему?

Ищите свои смыслы, пока Леха печатает..

Читать полностью…

Перепроданный фреймворк. ч.3 Причина

В этой части, мне хотелось бы высказать свое мнение о причинах распространенности методологии Scrum
В жизнь российского ИТшника Scrum ворвался ураганом. Произошло это одновременно с распространением принципов Agile. Отчасти поэтому до сих пор у многих Agile = Scrum, что конечно же не так.
Внезапно о нём начали говорить на крупных конференциях, в том числе и представители от бизнеса, такие как Герман Греф и тема завирусилась.
Scrum подкупал своей кажущейся простотой и понятностью. ИТ в России бурно развивалось, появлялось много новых лиц, и все следили за этим хайпом и хотели тоже попробовать.

Управленческое решение из коробки. Просто бери и делай

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

появилась волна спроса на "опытных Scrum-мастеров", но опытных не было.

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

⚠️ Продолжение читай в комментарии к посту🔽

Читать полностью…

Трекинг времени в IT 🤨
На днях пришлось дискутировать на тему внедрения трекинга времени для измерения эффективности разработчиков.
Я работал с трекингом и продолжаю им пользоваться, но персонально для себя. Поэтому довольно хорошо понимаю данную тему изнутри. И я вижу больше минусов от данной практики, чем плюсов:
Трекинг - это затраты. 💵Сотрудники будут терять от 5 до 10 процентов времени каждый день (зависит от организации). Записывать время просто только на словах. Даже у менеджера или аналитика (наиболее адаптированные к этому роли) будут возникать проблемы, ведь рабочий день не линеен. Тут отвлекли, там отвлекли, забыл включить, забыл выключить.. и как итог, нужно сесть и что-то придумать, чтобы интуитивно сделать корректную картинку дня. А это уже творческая работа.
Трекинг это снижение мотивации.😔 Постоянное отслеживание времени может вызывать у разработчиков чувство постоянного надзора, что снижает мотивацию и удовольствие от работы.
Трекинг не содержит реальных данных. Все зависит от отношения к нему каждого конкретного человека. Кто-то ответственно относится и тратит на него много времени и выдает реальную картину. Кто-то вписывает постфактум примерно, экономя свое время. А кто-то за счет трекинга находит удобный способ для правдоподобного описания своих затрат. Все зависит от типа людей в вашей команде.
Трекинг на самом деле никому не нужен. Цифры затраченных часов не показательны. По ним сложно сделать вывод о чем-либо и поэтому эти отчеты будут просто лежать. Мало кто действительно будет составлять по ним аналитические отчеты об эффективности того или иного сотрудника.

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

Подумайте над тем, доверяете ли вы своим людям, пока Леха печатает..

Читать полностью…

Карьерная рефлексия

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

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

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

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

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

Сюда отлично подходит, уже заезженная история про мужика и дерево:

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

Возможно, если регулярно затачивать вашу профессиональную пилу, то и раздражение на вопрос "Кем вы видите себя через 5 лет?" исчезнет 😉

🤓 - все равно душно
🤯 - картинка 🔥
👍 - побольше разнообразия в постах не повредит

Исследуй свои карьерные тропы, пока Леха печатает..

Читать полностью…

Перепроданный фреймворк

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

Сначала мне стоит оговорится, что Scrum - рабочий и распространенный фреймворк для разработки ПО. Но так уж сложилось, что те, кто пытаются внедрить Scrum, чаще всего сталкиваются со множеством проблем, которые решить не получается. (хотя казалось бы - фреймворк простой и звучит все складно) Но, как правило, все эти проблемы остаются на стороне “менеджера” и либо он талантлив и выкручивается, либо менеджера меняют, потому что он "недостаточно хорош". Стоит уточнить, что за менеджера в Scrum принимают Product Owner, который вообще-то (согласно методологии) ответственный за “максимизацию ценности, которую выдает команда”, и почти ни за что больше... стоит об этом задуматься 😉

Между тем, феномен того, что Scrum относится к Agile методологиям весьма загадочен, как по мне.

Данный фреймворк прямо заявляет:

Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless.

During the Sprint: No changes are made that would endanger the Sprint Goal;

The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum.

А вот Манифест Agile говорит:

“Responding to change over following a plan”

*привожу цитаты в оригинале, чтобы не грешили на перевод

В связи с этим, я не могу на 100% утверждать, что Scrum — это “гибкая методология”. Как минимум она будет самой жесткой среди гибких и даже жесче некоторых "не гибких"

Интересен ли дальнейший разбор методологий управления или поговорим о чем-то другом? 😊

🤓 - давай ещё!
🤯 - давай сменим тему

Подумай о коварности Scrum, пока Леха печатает..

p.s половину поста пришлось выпилить.. даже премиум не дает достаточной длинны сообщений 🙄

Читать полностью…

Демотиваторы

На самом деле, между предыдущими двумя постами произошла некая оказия 🤓

Знаете, бывает что ты чем-то загорелся и мотивация бурлит… вот и у меня такое было, когда только решил что буду развивать группу, вести LinkedIn, в общем попробую быть немного публичнее..
Написал пост, заполнил профиль в линкеде и начал добавлять людей в обе площадки.
Естественно, я подумал о том, что надо изучить тему как вообще развивать LinkedIn, но на первых порах все и так понятно - добавляй знакомых, у которых он есть, а изучу чуть позднее, когда контент будет 🤔 и будет что продвигать.
Какого же было мое удивление, когда на следующий день я обнаружил свой профиль забаненным. Причем не просто ограничения, а полный блок.. нельзя даже авторизоваться 🫤
Естественно, там есть алгоритм проверки документов (не их собственный кстати)… и, он не поверил моим докам. Сказал, что я это вовсе не я 🙃

Чтобы написать им в службу поддержки, сначала надо авторизоваться 🔥...
Чтобы вы понимали, за 1 день, с 0 контактов, я добавил около 80. Все подтвердили коннект. Отказов не было. Ну вроде логично же, когда человек с нулем, начинает развивать сеть, он добавит довольно много.. но я ошибся.
Это было как удар об стенку.. настолько выбило (хотя казалось бы) что я забыл как именно хотел развить мысль 😄 в предыдущем посте.
Так что пришлось перепридумывать как продолжить.
Итого, ушла неделя, но я таки смог разблокировать свой аккаунт, для этого понадобилось завести новый и с него доказывать что другой акк мой.
А в конце меня попросили удалить дублирующий аккаунт, так как иметь 2 - это нарушение правил сети 🙄

Кажется мне, что есть несостыковочки в их UX 😄

🤓 - ахахх, всегда перед тем как что-то использовать читаю правила использования
👻 - Linkedin ?! он что, ещё жив?
🤡 - накрутил ботов вот и бан 💯

Идите к своей цели не замечая стен и не теряйте мотивацию, пока Леха печатает..

Читать полностью…

Копипаста не работает

А мы можем скопировать из одного проекта и применить на нашем? - каждый лид неоднократно отвечал на данный вопрос. И, к зависти всех менеджеров, давал четкий ответ: “нет, так это не работает” (и чуть копнув, легко объяснить почему)

Но что мы видим в построении процессов управления? Процессы постоянно пытаются скопировать “у тех кто лучше” и применить у себя. Сколько копий сломано об аргумент “В Гугле/Эпле так, значит и нам надо так же”. С авторитетом больших корпораций сложно бороться. Факты, выкладки, объяснения… все это не перевешивает успеха корпорации-образца! Ведь “мы хотим быть как они!”, “у них это работает, надо делать также и мы точно станем лидерами”.

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

В разработке все нагляднее. У вас есть 2 проекта: Стек одного проекта C#+Haskell, а у вас PHP+JS… в обоих проектах нужен одинаковый функционал, но цели и применение разное. Даже если знать абсолютно все о первом проекте, то перенести крупный компонент из первого проекта во второй, будет...не практичным решением. В разработке такие вещи на поверхности и всем сразу понятны. Но не в менеджменте.

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

Quod licet Iovi, non licet bovi
Что дозволено Юпитеру, не дозволено быку

---
Эти размышления, у меня получают свое развитие в направлениях:

🧑‍💻 - про найм людей

🤓 - про процессы

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

Читать полностью…

Про менеджеров

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

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

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

Фокусируйтесь и согласовывайте цели, пока Леха печатает..

Читать полностью…

Продакты не нужны 2. Надо как у них
Допустим, продакт принял, что он не предприниматель. Но ведь можно искать смыслы в развитии продукта. Делать что-то важное, нужное и полезное... видеть реализацию в этом?
Тут стоит остановиться и подумать. А так ли много на рынке продуктов, которые действительно что-то и куда-то двигают? О которых с гордостью можно будет сказать — это сделал я 😎
На самом деле не так уж и много. Различных ниш, не так уж много. В любой из них, уже есть свои лидеры, на которых смотрят топ руководители остальных компаний. И когда ты работаешь не на лидера, неизбежно сталкиваешься с тем, что бэклог твоего продукта забит фичами типа "хочу как у них".
Много ли тут творчества и смысла? 😐

🔵Давайте посмотрим каковы шансы избежать спущенного сверху на годы вперед свалившегося бэклога:
1️⃣быть топом в своей компании и достичь просветления внедрить соответствующую культуру
2️⃣Работать в топ продукте в своей нише и желательно попасть в команду, которая не отвечает за "фичи", а занимается RnD. Много таких видели?
❌Работать в стартапе - не подходит, ведь продакты там не нужны. Продакт в стартапе появляется в двух случаях:
🔵Идея не выстрелила и нужно срочно сделать пивот. Нужна очень быстрая генерация и проверка идей
🔵От стартапа осталось только название, а по факту это уже рабочая бизнес модель, которую хотят улучшать.

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

Обдумывай свой карьерный трек, пока Леха печатает..

Читать полностью…

3 буквы для проверки гипотез: RAT, MVP, MLP
Гипотез по развитию продуктов генерируется много, а ресурсы всегда ограничены. Определить во что стоит вкладываться, а во что нет - одна из основных задач на уровне топ менеджмента. Каждая компания, по-своему подходит к данной проблеме исходя из своих собственных ограничений и стратегии (если она есть🧐). Но, по сути, все сводится к 4 вариантам:
1. Опираться на свою экспертность
2. Использовать RAT (Riskiest Assumption Test)
3. Использовать MVP (Minimum Viable Product)
4. Использовать MLP (Minimum Lovable Product)
В первом случае, ответственное лицо принимает решение и несет за него ответственность, а по остальным пройдемся чуть подробнее.
🔹RAT - предназначен для проверки ключевых предположений, которые могут критически повлиять на успех проекта на самых ранних этапах его разработки. RAT фокусируется на минимизации рисков и экономии ресурсов, позволяя быстро подтвердить или опровергнуть гипотезы, стоящие за продуктом или проектом. RAT стремится проверить самые критические предположения до любых инвестиций в разработку продукта.
🔹MVP. Этот метод у всех на слуху. MVP это уже реальный продукт с основной функцией (или несколькими) возведенной в абсолют, а все остальное отсекается. Часто это что-то без продуманного дизайна, с ошибками и без автоматизации
🔹MLP. Создается продукт, который не только функционален, но и вызывает положительные эмоции у пользователей. А для этого вкладываемся в дизайн и пользовательский опыт, чтобы сделать первое взаимодействие с продуктом приятным и запоминающимся

⚠️ Примеры применения подходов не влезли, так что добавлю их в комментарии к посту 👇

Читать полностью…

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

Цель стратегического планирования — это повышение эффективности бизнеса.

Чтобы повышать эффективность, нужно четко осознавать текущую ситуацию. Поэтому, перед тем как приступать к проработке стратегии, нужно произвести замеры и понять "а где мы сейчас". Думаю, что не сильно ошибусь, если скажу, что картина приближенная к реальности есть у 5-10% компаний.
Остальные 90%, могут лишь рассуждать о стратегии и воспринимать её как нечто эфемерное, вроде "идем туда", "наша миссия - нести добро" и т.д.
Можно возразить, что собственник "знает рынок", "понимает клиентов" и без данных, т.е. на уровне "чуйки". Но маловероятно что это действительно так.

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

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

👍 - тема интересная
🤓 - давай побольше про маркетинг
🤔 - лучше про процессы и менеджмент

Ищите точку опоры, пока Леха печатает..

Читать полностью…

​​Инструкция по общению с вашим «Вторым пилотом»

Последние полгода, стало достаточно модно обсуждать ИИ, а точнее его подмножество LLM. Часто это происходит в контексте «ИИ сожрет наши рабочие места» при этом какие именно - никому не ясно. Одни считают, что пострадавшими окажутся технические специальности, а другие что гуманитарные. Решил высказать свое мнение на этот счет.

О замене сотрудников

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

О текущем развитии LLM

В этом году Сэм Альтман пообещал выпустить GPT-5 который снимет многие текущие ограничения. Не так давно была запущена Gemini от Google, и в целом появляется много LLM. Большинство из них далеки от реального практического применения.

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

За год подобных продуктов появилось много. А в 2025 будет ещё больше.

И на этом тоже пытаются заработать предприимчивые люди. Я видел множество курсов по Prompt-ингу, которые обещают научить «разговаривать» с LLM и просят за это от 20 до 100 тыс. рублей

Я пользуюсь ChatGPT и DALL-E. Использовал Gemini. Уверен, что в 2025 актуально использование LLM в качестве «Второго пилота», который повышает вашу производительность. Но для продуктивного использования LLM нужно понимать, как они работают и как с ними «общаться»

В прикрепленном файле руководство по prompt-инжинирингу, которое содержит в себе все, что дают соответствующие курсы
Пользуйтесь 😉

Читать полностью…

Перепроданный фреймворк ч.2 Сроки

Следующее ограничение Scrum - ретроспективное планирование. Классическое тройственное ограничение проектного управления (сроки,стоимость,содержание) не работает для оценки успешности в данной методологии. Scrum верит только в удовлетворение “ожиданий заказчика” и нуждается в постоянной связи с ним. Логика примерно такова:

Экспертная оценка в ИТ – это, иллюзия. Её не бывает. Так что давайте не тратить время на попытку предоставить “точную оценку”. Вы можете постоянно наблюдать за тем, как мы работаем над тем, что Вам важно. Мы стараемся в нужном направлении. А если оно нужное, то какая разница? Давайте работать!

Разработчик определенно согласится с данным утверждением. 👍 А что менеджер? Ведь бизнес часто не готов выделять деньги без сроков и бюджета. Тут Scrum дает инструменты, которые позволяют ретроспективно планировать:

1) Scrum poker - игровая механика оценки задач, где команда дает оценки в “попугаях” используя карточки с цифрами по шкале Фибоначчи
2) Velocity (измерение мощность команды, вместо экспертной оценки)

Как это работает:
чтобы ответить на вопрос

когда сделаете?

нужно узнать “Мощность” команды. Нельзя измерять “мощность” на конкретного разработчика, так как это противоречит Scrum, который оперирует "командой". Для того чтобы получить “мощность”, надо дать команде поработать несколько отрезков и посмотреть, сколько “в среднем” попугаев, команда производит за 1 отрезок. После чего, вы сможете понять сколько времени вам нужно чтобы закрыть ваши задачи, которые оценены в "попугаях" 🦜🦜🦜

Но по факту, вы почти никогда не будете этого понимать. 😐 У людей есть болезни, отпуска, увольнения и прочее. Кроме них, у развития команд есть ещё и стадии по модели Такмена. И каждый раз, когда с командой что-то происходит, её “мощность” нелинейно меняется!

Таким образом, предсказать сроки завершения крупного проекта, используя инструменты Scrum - практически невозможно. (А ведь их хотят знать ещё и до старта😱)

(Пере)Согласовывай сроки, пока Леха печатает..

Читать полностью…

немного специфичного юмора на злобу дня 🥲

Не бойтесь проводить эксперементы, пока Леха печатает..

p.s. этот пост, эксперемент с форматом

Читать полностью…

Про процессы

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

1. На каком этапе развития находится компания
2. Команда людей, с которыми вы работаете/будете работать

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

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

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

Квалификация и мотивация сотрудников будут прямым образом влиять на то, какие процессы стоит внедрять и каким путем идти. по сути есть 2 варианта как действовать:
1.Определить с кем нужно строить, и организовать процессы под то “что имеем”
2.Прописать процесс, и под него нанимать людей

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

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

🦄 — delivery&discovery - давай проще

🤝 — спасибо, кэп!

🌚 — нормально делай, нормально будет

Посмотри на людей вокруг, пока Леха печатает..

Читать полностью…

Let's talk about legacy 🕵️‍♂️

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

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

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

🔥— легаси наш дом родной

🤡— работать с легаси - фу!

Говорите о легаси без смущения, пока Леха печатает..

Читать полностью…