#полезности #знания #мнение

Почему Story Points, а не человеко-часы, и как это работает на самом деле? 🤔
Часть 1

Почему это может быть более эффективным подходом:
1️⃣ Абстракция: Story Points оценивают сложность задачи, а не просто время, необходимое для ее выполнения. Это учитывает неопределенность и риск, что делает оценку более реалистичной.
2️⃣ Гибкость: Оценка в часах предполагает, что все члены команды работают с одинаковой скоростью, что редко бывает верно. Story Points учитывают различия в производительности и опыте членов команды.
3️⃣ Фокус на ценности: Использование Story Points помогает команде сосредоточиться на доставке ценности, а не просто на выполнении задач. Это способствует более продуктивной и сотрудничеству ориентированной культуре.
4️⃣ Меньше давления: Оценка в часах может создать давление на команду, чтобы они работали быстрее, что может привести к снижению качества. Story Points позволяют команде работать в более расслабленном темпе, сохраняя при этом высокую производительность.

❗️Однако, важно понимать, что Story Points и оценка в часах не взаимоисключающие. Они могут работать вместе для достижения большей точности.

Story Points — это мера, которая используется в Agile и Scrum для оценки сложности задачи. Они не имеют абсолютного значения и служат для сравнения относительной сложности различных задач в рамках одного проекта.
1 Story Point обычно определяется как наименьшая единица работы, которую команда может выполнить. Это может быть, например, простая задача, которую можно выполнить за короткое время без значительных усилий.

Определение значения Story Point может быть сложным, и это часто требует обсуждения в команде. Вот некоторые стратегии, которые могут помочь:
1️⃣ Сравнение задач: Команда выбирает две задачи и обсуждает, какая из них сложнее. Затем они присваивают этой задаче больше Story Points.
2️⃣ Метод покер-планирование: Каждый член команды оценивает задачу в Story Points независимо. Затем команда обсуждает свои оценки и приходит к соглашению.
3️⃣ Использование шкалы Фибоначчи: Задачи оцениваются по шкале Фибоначчи (1, 2, 3, 5, 8, 13, и т.д.), что отражает неопределенность и риск, связанные с более сложными задачами.

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

Story Points дают нам общее представление о сложности задачи, а затем мы можем использовать исторические данные о скорости работы команды (сколько Story Points команда обычно завершает за итерацию) для преобразования этих Story Points в конкретные сроки. Это называется скоростью команды (velocity).
Например, если ваша команда обычно завершает 20 Story Points за двухнедельную итерацию, и у вас есть задача, оцененная в 5 Story Points, вы можете ожидать, что эта задача будет завершена примерно за треть этого времени, то есть примерно за 5 дней.
Этот подход учитывает многие факторы, которые трудно учесть при оценке в часах, такие как прерывания, затраты времени на согласование и общение, технические трудности и так далее. Это делает его более гибким и адаптивным, что особенно важно в быстро меняющемся мире IT.

А если это новый проект и нет никаких исторических данных о производительности команды?

В новом проекте, когда у нас еще нет исторических данных о скорости команды, оценка может быть более сложной. Однако, даже в этом случае, Story Points могут быть полезными.
Во-первых, мы можем начать с оценки задач в Story Points, чтобы получить представление о сложности каждой задачи относительно других. Затем мы можем использовать опыт и знания команды, чтобы сделать образованную догадку о том, сколько Story Points команда может завершить за итерацию. Это будет нашей начальной скоростью (velocity).
Во-вторых, после первой итерации у нас будут реальные данные о скорости команды, которые мы можем использовать для более точного прогнозирования в будущем. С течением времени, по мере того как команда продолжает работать над проектом, наши прогнозы станут все более точными.

#полезности #знания #мнение

Почему Story Points, а не человеко-часы, и как это работает на самом деле? 🤔
Часть 2

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

Приведу приближенный к реальной ситуации пример:

Допустим, у вас есть новый проект по разработке мобильного приложения. Вы с командой провели сессию планирования и определили следующие основные задачи:
1️⃣ Дизайн пользовательского интерфейса
2️⃣ Разработка базы данных
3️⃣ Разработка API
4️⃣ Тестирование и отладка

Вы оценили каждую задачу в Story Points следующим образом:
1️⃣ Дизайн пользовательского интерфейса: 13 Story Points
2️⃣ Разработка базы данных: 8 Story Points
3️⃣ Разработка API: 5 Story Points
4️⃣ Тестирование и отладка: 20 Story Points

Общий объем работы составляет 46 Story Points.

Теперь, допустим, вы предполагаете, что ваша команда может выполнить около 10 Story Points за двухнедельную итерацию (это ваша начальная скорость). Используя эту оценку, вы можете предсказать, что проект будет завершен примерно за 5 итераций, или 10 недель.
Это, конечно, приближенная оценка, и реальные сроки могут отличаться. Однако, это дает вам и вашему заказчику общее представление о том, сколько времени может занять проект, и позволяет вам начать планирование.
После первой итерации у вас будет реальные данные о скорости команды, которые вы сможете использовать для корректировки вашего прогноза. Это одно из преимуществ использования Story Points и Agile методологии — они позволяют вам адаптироваться к изменениям и уточнять ваши прогнозы по мере продвижения проекта.

Окей, а как понять, сколько это будет в реальных единицах времени?

Для расчета времени выполнения проекта нам нужно знать скорость команды (velocity), то есть сколько Story Points команда обычно выполняет за итерацию. Допустим, скорость команды составляет 10 Story Points за двухнедельную итерацию (это пример, и реальная скорость команды может отличаться).
Тогда, если общий объем работы составляет 46 Story Points, мы можем вычислить количество итераций, разделив общий объем работы на скорость команды:

🔖 Количество итераций = Общий объем работы/Скорость команды = 46 SP/10 SP в итерацию = 4.6 итераций

Поскольку каждая итерация длится две недели, общее время выполнения проекта составит:
🔖 Время выполнения проекта = Количество итераций Х Длительность итерации = 4.6 Х 2 недели/итерацию = 9.2 недели

Итого: примерно 9 недель и 1 день. Учтите, что это приближенное значение, и на самом деле время выполнения проекта может варьироваться в зависимости от многих факторов, таких как, например, стабильность интернет-соединения и др; технические проблемы, человеческий фактор, экономический, политическикй, прочие риски.

Если в команде вы используете относительную оценку задач, то какие цифры окончания работ мне как ПМу нужно озвучить заказчикам и стейкхолдерам?

Я бы использовал данные о скорости команды (velocity), чтобы преобразовать Story Points в конкретные сроки для заказчиков и стейкхолдеров.
Например, если команда обычно выполняет 10 Story Points за двухнедельную итерацию, и у нас есть проект, оцененный в 50 Story Points, я бы сообщил заказчикам, что проект, вероятно, будет завершен примерно через 5 итераций, или 10 недель.
Это, конечно, приближенная оценка, и реальные сроки могут отличаться. Однако, это дает заказчикам и стейкхолдерам общее представление о том, сколько времени может занять проект, и позволяет им начать планирование.
Важно помнить, что все оценки являются прогнозами и могут быть неточными. Главное — это не точность, а то, как мы используем эти оценки для управления проектом и обеспечения его успешного выполнения.

#полезности #знания #мнение

Почему Story Points, а не человеко-часы, и как это работает на самом деле? 🤔
Часть 3 (финалка)

❗️Все три части рекомендую читать строго по порядку, а не отдельно одну.

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

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

Допустим, что каждый Story Point соответствует одному дню работы. Тогда продолжительность каждой задачи будет следующей:
1. Дизайн пользовательского интерфейса: 13 дней
2. Разработка базы данных: 8 дней
3. Разработка API: 5 дней
4. Тестирование и отладка: 20 дней

Теперь давайте предположим, что задачи должны выполняться в следующем порядке:
1. Дизайн пользовательского интерфейса
2. Разработка базы данных
3. Разработка API
4. Тестирование и отладка

Тогда критический путь будет включать все эти задачи, и общее время выполнения проекта будет равно сумме времени выполнения всех задач на критическом пути, то есть 13 + 8 + 5 + 20 = 46 дней.

А как бы выглядела диаграмма критического пути для этого проекта?

Представьте себе таблицу с четырьмя строками, по одной на каждую задачу (A, B, C и D). В каждой строке есть два столбца: один для раннего старта и финиша, и другой для позднего старта и финиша.
• Задача A (Дизайн пользовательского интерфейса) начинается в день 0. Она длится 13 дней, поэтому ранний и поздний финиш — это день 13.
• Задача B (Разработка базы данных) начинается сразу после завершения задачи A, то есть в день 14. Она длится 8 дней, поэтому ранний и поздний финиш — это день 22.
• Задача C (Разработка API) начинается сразу после завершения задачи B, то есть в день 23. Она длится 5 дней, поэтому ранний и поздний финиш — это день 28.
• Задача D (Тестирование и отладка) начинается сразу после завершения задачи C, то есть в день 29. Она длится 20 дней, поэтому ранний и поздний финиш — это день 49.
Критический путь — это последовательность всех этих задач, потому что они должны выполняться одна за другой, и ни одна из них не может быть отложена без влияния на общий срок выполнения проекта.

🔗Как выглядела бы схема этого примера можно посмотреть ЗДЕСЬ.

​#инсайты #горькаяправда #моимысли

Я думаю многие в курсе, что рынок ИТ до сих пор переживает не лучшие времена... Недавно читал новость, что пошла очередная волна сокращений в мире. Это затрагивает и международный рынок, и страны СНГ, которые работают с зарубежными заказчиками. Чуть лучше себя чувствуют продуктовые компании. Причины разные: экономический кризис, ИИ, перенасыщение инвестиций инвесторов и венчурных фондов в стартапы с 20-21-го годов. Вот, результат.
Самая главная проблема относительно рабочих мест, на мой взгляд — это ИИ, который развивается бешеными темпами. Что разработчики негодуют, что менеджеры или маркетологи. Там, где ИИ может технически или визуально что-то заменить/создать с нуля дешевле рабочей силы, те специалисты в опасности. Возможно, чуть в более выигрышной позиции роли, где нужно управлять человеческими ресурсами и обслуживать сервисы и(или) hardware на базе AI/ML.

Как снизить риски, быть востребованным и не остаться на морозе? Рецепт простой:

1. Следить за новостями рынка и постоянно обучаться новому, актуальному типа ИИ-инструментов, Machine Learning, RPA, Deep Learning, etc., и думать, где это можно применить в своей работе либо присматривать новое место с такими направлениями, т.к. технологии будут развиваться и эволюционировать в этом направлении еще очень долго.
2. Переквалифицироваться со специальности, которая в вашей зоне риска. На мой взгляд, это копирайтеры, маркетологи, таргетологи, визуализаторы и некоторые дизайнеры, тестировщики в какой-то степени и т.д.
3. Брать инициативу в свои руки и создавать новые рабочие места самому. Сейчас рынок не кандидатов, а нанимателей. Конкуренция большая. Любой кризис — это возможности! Просто знайте это. Их только найти нужно. Поэтому это одна из причин, почему я создаю свой продукт с современными технологиями и набираю команду.

Кстати, у меня есть две новости:
1. У нас в проекте появился разработчик, с которым мы будет разрабатывать нашу умную платформу.
2. Освободилось место для PM. В пятницу опубликовал пост об этом в Linkedin. За полдня я получил больше 15 заявок в личку(!). Учитывая, что я не рекрутер/HR, я думаю, это близко к много. В тот момент я в какой-то степени прочувствовал боль рынка в лице кандидатов как наниматель, что даже на пет-проект люди готовы идти, чтобы получить/прокачать/поддержать в тонусе свои навыки. 😢 Однако, я понял, что еще сильнее хочу реализовать свою цель, чтобы помочь людям, дав им крутой и удобный инструмент, который максимально поможет решить их задачи.

А вчера я поделился со своим HRBP/СОО безумной идеей, но очень крутой — решения вопроса урегулирования процесса найма с двух сторон. Рассказывать пока не буду. Все узнаете со временем.
Я очень верю и надеюсь изменить процессы в области найма в ИТ. А может, и не только в ИТ. 😌 Главное, чтобы хватило ресурсов, мотивации, сил и энергии, ну и поддержки людей со стороны. Она очень подбадривает. 🫱🏻‍🫲🏽

#юмор #горькаяправда 😁

#новости #полезности

OpenAI только несколько часов назад выпустила инструмент Sora, который позволяет генерировать видео по тексту! Теперь можно превращать идеи и скрипты в видеоролики. 🚀🙀

Подробнее на инструмент тут: https://openai.com/sora

#кейсы

Запускаю рубрику кейсов.
Суть проста:
Я публикую ситуационный кейс. Вы в комментариях пишете свое мнение по решению этого кейса. Как правило, в подобных кейсах нет единого правильного ответа. Все основывается только на нескольких факторах, например, таких как: здравый смысл, бизнес-ценности заказчика и(или)компании, сроки проекта, логика и т.п. Все кейсы с позиции менеджера.
Итак, полетели! 🚀


Кейс №1.

Контекст:
Вы — Проектный менеджер в небольшой международной аутсорсинговой ИТ-компании, где нет ни одного русскоговорящего сотрудника, кроме вас. В этой компании вы работает уже 6-й месяц. Команда состоит преимущественно из филиппинцов, иранцев, иракцев, пакистанцев, индийцев. В работе у вас 6 проектов. Команда на все проекты — 30+ чел. Все проекты разной сложности, условиями и заказчиками. Один из проектов — самый серьезный с точки зрения бюджета, сроков, важности заказчика. Дедлайны на нем и некоторых других конкретные и четкие. Вы уже прошли стадию знакомства с командой, наладили контакт так, что команда склонна вам доверять и видит в вас лидера. Работа в офисе. 5 дней в неделю. Все, вроде бы, идет неплохо. Но в один из дней в офис не приходит ваш Тим Лид. Ни вас, никого другого о своем отсутствии заранее он не уведомил. До этого у вас с ним конфликтов и поводов никаких не было. С командой, вроде бы, конфликтов не наблюдалось. Настроение у него было, как всегда обычное. Что вы будете делать в этой ситуации? 🤔

​#кейсы #инсайты

Так как предыдущий кейс — мой реальный, то я расскажу, как я поступил и что конкретно сделал.

1. Это Тим Лид (назовем его Петя), а не обычный рядовой тиммэйт.
2. В работе у нас было несколько проектов, на которых он был задействован. Также, были задачи с конкретными сроками, за которые он был ответственен, его команда, за которыми он следил, координировал, ревьюил код и т.д.
3. Человек не удосужился банально уведомить ни меня, ни даже своего члена команды.

Алгоритм действий:
1. Поинтересовался у команды, а затем у СЕО, где он. Никто не знал.
2. Написал ему. Спустя 2-3 ч — тишина. Позвонил — тишина.
3. Обратился к его коллеге (назовем Коля), с которым он сидел рядом и часто общался. Тот тоже не знал, где Петя. Тогда я попросил Колю связаться с Петей.
4. Пошел к СЕО сообщить о случившемся, дабы у нее не было вопросов. Поинтересовался, как часто от Пети случается такое. Узнал, что часто. Это уже 6-7 раз в теч. года. Офигел. Понял причину, почему Петя не выглядел лидером для команды — безответственность. СЕО тоже пыталась связаться с Петей. Облом.
5. Ушел думать, что с ним делать. Параллельно анализировал статус задач, прикидывал, где мы можем просесть из-за отсутствия Пети мин. на день-два.
5. После обеда Петя ответил Коле — он устал и решил(!) взять выходной. Второй раз офигел от его поведения. Мой коллега тоже. Раз уж он ответил только Коле, то попросил Колю узнать у Пети, когда тот вернется — завтра или(!) послезавтра.
6. Злой ушел размышлять, что с этим можно сделать, как поступить, когда Петя вернется — наказать или нет.
7. Петя вернулся через 2 дня. После анализа статуса задач и сроков, решил, что более правильно будет сфокусироваться на проекте, срок сдачи которого был ближе всего => не ломая производительность Пети выговором и давлением.
8. Вызвал его на беседу 1-1. Сперва поинтересовался о его самочувствии и что он сам думает об этом всем. Он согласился, что неправильно поступил. Я же лишь спокойно и тактично призвал его к ответственности, напомнив, что такое поведение некорректно само по себе и что мы все договорились соблюдать правила об уведомлении, если что-то случается. Он согласился и пошел на рабочее место.

Резюме:
Отсутствие члена команды без уведомления спровоцировало конфликт и очередной раз подорвало его репутацию со стороны команды и руководства.
Я выбрал мягкую модель диалога с ним, чтобы остаться друзьями, а не врагами. После диалога Петя не был раздражен или напуган, не был в стрессе — все то, что могло снизить его производительность. Я понимал, что низкая производительность может растянуться на какое-то время и вызвать проблемы со сроками и(или) качеством продукта.
Тем не менее, после долгих размышлений и анализа, к сожалению, я пришел к решнию, что после сдачи важного проекта, на котором он работал, нам с ним придется расстаться. С таким вариантом согласилась и СЕО, т.к. систематическое нарушение корпоративных правил, дисбаланс и разобщенность в команде нам было не нужно. Забегая наперед, после его увольнения, команда стала более оживленной и сплоченной.

#новости #горькаяправда

Уверен, многих интересует, почему, все же, лопнул пузырь ИТ и каковы этому причины. 🧐 Лично я интересуюсь этим с прошлого года, общаюсь с разными экспертами, мониторю рынки. И не так давно я наткнулся на интересный пост одного парня, который детально на примере объяснил одну из главных причин. До этой информации, я лишь догадывался, т.к. конкретных аргументов я не находил. А теперь они есть. Так вот, одна из главных причин кризиса в ИТ — это Закон №174. Согласно положению этого Закона компании, которые ранее могли получить налоговые льготы на развитие и исследования (R&D), теперь вынуждены платить значительные средства, даже если они работают в убыток. Это в США. Однако многие европейские государства тоже рассматривают такую практику. Отсюда и в Европе большая конкуренция на рабочие места помимо США.

🔗 Чуть детальнее можно почитать, что писал парень здесь.

#горькаяправда #мнение #моимысли

Английский или чего никогда не сделает русскоговорящий

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

Так вот, который раз я убеждаюсь, что русскоговорящие НЕАДЕКВАТНО оценивают твои знания, и так же нетактично ведут себя в этом плане. Сегодня я общался с Product Director в рамках финального интервью одной компании. Она — американка из Флориды. Беседа была в полунеформальном формате.
Я получил от нее непредвзятый, откровенный фидбэк, что у меня отличный английский! Добавила, что это непросто знать чужой язык и так мочь передавать мысли бегло. Было очень приятно такое слышать.

Каждый русскоговорящий, изучая иностранный язык, немного/много принижает свои достижения и навыки, почему-то. Такие уж мы. 🤷🏻‍♂️ Это плохо, кстати. Нужно переучиваться. В таком окружении это непросто, но возможно.

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

#мойстатус #моимысли #новости #партнерский_материал

Заметка дневника.
Ни для кого не секрет, что последние 2 года рынок ИТ переживает непростые времена. Поэтому поиск работы становится очень актуальным для кандидатов. На этой почве я уже набил руку, т.к. сам был в поиске, и смело могу сказать, что работает хорошо, а что нет. Особенно для менеджерских позиций. К поиску ведь нужно относиться тоже как к проекту, следовательно, нужно организовать и настроить процесс, подготовить окружение и необходимые инструменты, просчитать риски и т.п. Ко мне даже обращаются некоторые ребята за консультацией. Честно сказать, я испытываю приятные ощущения от помощи. Это здорово! Поэтому если нужна консультация в помощи составления эффективного резюме, упаковке классного Linkedin, который будет привлекать работодателей и к вам будут добавляться интересные контакты, а ваша аналитика повысится минимум в х5 раз, то велкам.

Скоро состоится важное мероприятие для ПМов — ProductCamp. Я уже второй год сотрудничаю с ними. На этот раз я пишу для них статью упаковки резюме и Linkedin-профиля. Тезисно. Ключевые моменты. Надеюсь, моя статья выйдет в прод и будет красоваться на их странице. 🙌🏻

#полезности #знания

Вчера ProductCamp опубликовал мою статью “Как стать звездой на рынке ИТ: резюме и LinkedIn, которые покорят работодателя”. Статья будет полезна тем, кто сейчас находится в активном поиске работы на международном рынке и рынке СНГ. А также тем, кто только планирует выход в поле. Запомните, перед "боем" нужна хорошая подготовка. С ней вы будете вооружены и очень опасны. Поэтому рекомендасьон-лосьон к прочтению. 😉

Также, сообщаю, что я точечно и в индивидуальном порядке помогаю “упаковаться” специалистам для поиска. Особенно на менеджерские позиции. Даже если вы С-левел.👑 Конкретные пункты (1-15), в чем я могу помочь можете посмотреть по ссылке здесь.

#мнение #полезности #моимысли

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

#кейсы

Кейс №2. Гарантийная поддержка.

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

❕Сразу оговорюсь, кейс не мой, но он реальный. Есть решение, какие действия были предприняты. Однако давайте сперва ваши версии обсудим.

#кейсы решение кейса №2.

Спасибо всем, кто принял участие в кейсе. 🫱🏻‍🫲🏼 Как и обещал публикую, чем он закончился в реальности.

После сложного и долгого MVP с большим количеством отладки и организационно сложной приемкой ребятам на стороне разработки (вендор) никак не хотелось соглашаться на полгода бесплатной поддержки. Аргументы ребят разбивались о пункт договора, на который при любых аргументах ссылался PM клиента. Решение нашел CEO компании-разработчика. Он позвонил руководителю “вражеского” PMа и сказал: “Мы небольшая аутсорс-компания, а вы — большой банк. Мы не можем позволить себе бесплатно поддерживать ваш продукт. Для вас это несущественный бюджет. Вы можете подать на нас в суд и, наверняка, выиграете. Мы от этого закроемся и не сможем развивать наш продукт. Поэтому мы не подпишем SLA. А вы хотите продолжать с нами работу?”. Клиентский руководитель сказал да. В итоге соглашение вообще не было подписано. А сам банк спустя полгода перестал существовать в первоначальном своем виде.

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

#полезности #мнение #знания

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

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

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

Middle
Специалист, который уже умеет. Хорошо ориентируется в специфике домена(ов). Вовремя решает поставленные задачи. Самостоятельный, но может обратиться и за помощью.

Senior
Систематизирует и оптимизирует работу. Вносит ценную экспертизу. Обучает младших специалистов и комментирует их работу. Более самостоятельный — решает задачи и возникшие сложности преимущественно сам.

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

Manager
Специалист с релевантным опытом. Умеет планировать, делегировать, контролировать и мотивировать. Понимает сильные и слабые стороны сотрудников и умеет направлять их усилия в нужное русло. Самостоятельный специалист, который решает поставленные задачи и распределяет их среди других специалистов. Как правило, подчиняется вышестоящему руководителю, обычно, Head of PMO, CEO.

А вы согласны с такими формулировками?

#кейсы

Кейс №3

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

Что вам стоит сделать в такой ситуации? Можно ли выстроить диалог с директором, если да, то как?

#кейсы

Решение кейса №3

Была попытка выстроить с директором личные отношения, объяснить, что такой стиль взаимодействия не подходит. Но это не помогло. Команда клиента подтвердила, что агрессия не редкость и он привык так управлять. Выяснилось, что в подчинении директора есть техдир, мнение которого было важно директору, поэтому обратились к нему с просьбой оградить нас от директора через его подчиненных. Техдир пообщался со своим руководителем, и мы начали получать требования через команду директора. Директор продолжал присутствовать на созвонах и иногда устраивал скандалы, как и раньше. После повторного разговора с директором и тех диром решили отказаться от проекта, т.к. это сказывалось на команде, продукте и успешности проекта. Самое интересное, что клиент потом попросил нас вернуться, директора обещали изолировать, но на самом деле внутри у них ничего не изменилось и по сей день. Мы сделали еще два обновления и расстались.

То есть, по сути, это эскалация проблемы. В комментах добавлю некоторые детали.

​#знания #полезности #мнение #инсайты

Про методы Теда Лассо

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

1) Не бойся показаться глупым. Вот вообще, никогда. Потому что лучше 10 или 100 раз переспросить, но понять, чем делать вид что ты понял то, что на самом деле прошло мимо тебя. Глуп не тот, кто не знает, глуп тот, кто делает вид, что умен.

2) Не бойся показаться слабым. Супергерои из DC и Marvel даже у школьников потеряли популярность, важно уметь признавать поражения и не делать вид что все шикарно тогда, когда все на самом деле хреново

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

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

5) Временами сумасшедшие идеи работают, просто в них нужно верить. Нет, не так, ВЕРИТЬ. И способность услышать классную идею и поверить в нее не отмахиваясь - мощнейшая штука

6) Даже если ты споткнулся 20 раз подряд есть высоченная вероятность, что в 21й все получится. И если рядом те, кто с тобой заодно, то вероятность будет еще выше, ты только не сдавайся.

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


Потрясающая заметка автора Сергея Щербинина