Инструменты для управления задачами

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

Jira
Топ-1 инструмент для ведения задач по scrum (т.е. спринтами). На самом деле jira не заблокирована, но для ее оплаты нужно обзавестись иностранной картой.
Если для вас это не проблема - однозначно туда.

Trello
Топ-1 инструмент для ведения задач по Kanban (т.е. на доске).
У trello тот же создатель, что и у jira, но есть мощное преимущество - можно работать бесплатно.
В бесплатной версии нет ряда "удобств", но для небольших проектов и этого хватит с запасом.

Российские аналоги
Приведу два инструмента, каждый из которых слабее, чем jira, но вполне пригоден, если вам нужно с чего-то начинать.
Это:
1. www.wrike.com
2. www.flowlu.com

Сознательно пропустил ЯндексТрекер - он кривой до ужаса, если есть те, кто с ним справился - поделитесь опытом.

Заменители Jira, с которыми нужно уметь работать
Есть еще два инструмента, которыми можно полноценно перекрыть jira, но их настройка требует навыков и опыта, это:
1. Youtrack
2. Redmine

Послесловие
А еще любую работы можно организовать с помощью Excel.

Если вы используете другие инструменты и вам нравится - обязательно поделитесь в комментариях и мы выпустим обновление этого обзора.
Давайте помогать друг другу:)

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

Мотивация IT-специалистов

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

Сегодня я хочу поделиться результатом исследований на тему мотивации технических специалистов.
Более 1000 специалистов спросили, что демотивирует их больше всего в работе.

ТОП-3 фактора достаточно предсказуемы и выглядят следующим образом:

1. Токсичная атмосфера в коллективе
2. Отсутствие оплаты за регулярные переработки
3. Непрофессиональный руководитель и плохая постановка требований

Мне было интереснее посмотреть последние места рейтинга, куда попали:

1. Отсутствие дополнительных "плюшек" на работе - последнее место в выборке
2. Когда кто-то говорит, как лучше делать работу - IT специалисты самодостаточны и не обращают на такое внимание
3. Большое количество работы, отсутствие обратной связи от руководителя и поддержки от коллег - все это также не трогает тех, кто выбрал для себя путь логики

Проекты, продукты и процессы
Начнем познавать теорию управления проектами #theory

В мире управления проектами различаются три фундаментальных термина:
1. Проекты
2. Продукты
3. Процессы

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

Проекты могут быть большие (построить футбольный стадион) и совсем маленькие (починить разбитый телефон).

Главный по управлению проектами: руководитель проекта (project manager).
Он знает, как делать проекты.

Продукт
Продукт - это результат проекта (возможно нескольких проектов), который приносит пользу (положительную или отрицательную, другой вопрос).

Стадион - это продукт (его строили, чтобы продавать аренду, билеты и рекламу). Яблоки на рынке, айфоны в магазине - все это продукты.

Главный по управлению продуктами: руководитель продукта (product manager).
Он знает, какие продукты нужны людям и как их продвигать.

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

Если мы чиним телефон - для нас это проект.
Для мастера, который чинит телефоны один за другим это уже процесс.
Компания, в которой работает мастер - это продукт.

Запомните, не путайте, дальше будем усложнять:)

🔥Тушение пожаров🔥
Результаты вчерашнего опроса меня немного удивили, давайте разбираться.

Начнем с того, что пожары бывают разные.

🔥Лесные пожары🔥
Если мы имеем дело с регулярными пожарами (прямо как лесные пожары у нас или в США), то справедливо замечание из комментариев - "дайте догореть".

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

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

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

При этом "разбираться" - это не отфигачить исполнителя до полусмерти, а назначить с ним встречу (желательно тет-а-тет или хотя бы без участия "карателей"), понять причины, а уже потом лично отчитаться о сделанных выводах.

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

Выстраивание коммуникаций

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

Что нам нужно сделать:
1. Определить, перед кем будем отчитываться - составим табличку со стейкхолдерами
2. Согласуем, как мы отчитываемся - для больших людей это могут быть показы с презентацией, другим хватит письма со статусом
3. Согласуем регулярность отчетности - большие показы раз в месяц, письмо раз в неделю
4. Придумать состав отчета, об этом ниже

Идеальный отчет о чем угодно - это одна большая лампочка, которая горит красным или зеленым🚥

На мой взгляд статус по проекту должен содержать:
1. Короткое текстовое описание основных новостей - 88% получателей прочитают только его
2. Сроки - находимся ли мы в плане или нет
3. Бюджет - аналогично срокам
4. Ресурсы - есть ли проблемы с командой, нужен ли кто
5. Риски - основные незакрытые риски, заодно привыкнем их вести

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

PS Чтобы поместиться в лимит символов, пришлось заплатить телеграмму неслыханные 300р, это ли не стоит вашего репоста:)

Переработки
Как-то так вышло, что последнее время я работаю по 10-16 часов в день и задумался, что с этим делать…

Как истинный зануда, я опросил 10 друзей, которые работают на руководящих позициях и выяснил, как они справляются с переработками.

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

1. Понимание цели - у одних это профессиональный рост, у других деньги, но у каждый из опрошенных четко понимал, зачем он делает то, что делает.

2. Отдых - определите время или день, в которое вы 100% не работаете (у меня это суббота). Сюда же можно отнести регулярный отпуск.

3. Сон - банально, но правда. В условиях высокой нагрузки сон становится критически важным и большинство опрошенных серьезно за ним следят (кстати в тему сна очень советую книгу «Зачем мы спим»).

4. Хобби - работа не должна занимать 100% времени, выберите спорт, путешествия, семью, да что угодно, на что будете переключаться (по факту это дополнение к п.1)

5. Если сгорели, возьмите паузу и подумайте, а туда ли вы копаете и здесь я обязан поделиться цитатой автора одного прекрасного канала:
"Просто когда выгораешь, главное не копаться в пепелище, а найти силы в нем что-то прорастить".

Этот шедевр вчерашнего опроса не должен остаться незамеченным, позитивных выходных вам, друзья!

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

Project manager (PM)
Наше все - человек, который отвечает за выполнение проекта за заданное время и в рамках бюджета.
Важно, «по определению» менеджер проекта контролирует именно планы, т.е. чтобы написанное в техническом задании было сделано вовремя и компания не потратила на это больше, чем заработала.
На больших проектах менеджеры проектов могут вообще не погружаться в технические детали.

Project manager officer (PMO)
Руководитель менеджеров проектов. Если такой роли нет, этим занимается CTO (технический директор). Когда в компании много проектов, кто-то должен распределять ресурсы между ними и контролировать работу PM-ов, это как раз PMO.
Если нам для проекта нужен дополнительный разработчик, который есть в соседней команде, мы просим его именно через PMO, а не нагло воруем (хотя второе и проще).

Delivery manager
Достаточно редкая роль и чаще это архитектор.
Менеджер доставки решений отвечает за техническую сторону проекта: определяет стек технологий, политики разработки, объясняет разработчиком, что и как у нас устроено внутри.

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

Sales manager
Человек, которого все не любят.
Он продает наши продает наши продукты новым клиентам и зачастую немного приукрашивает, а нам потом разгребать.

Product manager
Служит внутренним заказчиком для project manager-ов.
Отвечает за развитие продуктов компании, анализирует аудиторию, формирует гипотезы, прикидывает потенциальную прибыль.

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

Важный анонс!
Обещали - выполняем

7 июля (завтра) в 20:00 в прямом эфире общаемся с:
- Ex исполнительным директором и лидером мобильной разработки Сбера,
- Директором IOS Podlodca Crew,
- Head of mobile 3commas,
Евгением Ртищевым

Где пройдет
За час до интервью в канале появится ссылка-приглашение.
Присоединиться и задать вопрос сможет любой желающий.

Что будем обсуждать
Мы старые друзья, конкретного плана нет, но точно обсудим:
- Сбер, как место работы и культуру ведения проектов внутри
- Релокацию (Женя перебрался в иностранный стартап)
- Крипту (то, чем Женя занимается теперь)

Скоро начинаем!

В 20:00 стартует наше первое интервью с Женей, подключиться можно по ссылке
Тайминги: 1,5 часа (общение + ваши вопросы)

Это будет первый подобный опыт, минимум подготовки, максимум импровизации.

Успехом буду считать аудиторию в 20 человек.
Репосты категорически приветствуются :)

Мы это сделали!

Нас было не много, но получилось интересно, желание продолжать выросло🔥
Огромное спасибо @katleta3000 за интервью и каждому присоединившемуся❤️

Мы вырежем особо откровенные куски и через пару дней разместим запись для остальных😉

7 красных линий
Минутка юмора

За много лет это по прежнему самая правдивая короткометражка про работу в корпорациях и не только:

https://youtu.be/8BctbPxfVQ8

Менеджмент в IT, Сбер, крипта и релокация

Интервью с Женей обработано, а чтобы картинка из zoom не была совсем скучной, немного поиграл в режиссера:)

https://youtu.be/yIZWcZw58e0

Unit test

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

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

Звучит полезно, но у юнит-тестов есть и обратная сторона медали:
1. Время на написание - создание теста занимает около 50% от написания самого функционала
2. Поддержка - если мы правим функционал, то придется править и тест этого функционала
3. Еще больше ошибок - если тесты написаны плохо, вам придется править и функционал и сами тесты

Тем не менее на больших проектах со сложной логикой и множеством зависимостей без тестов далеко не уедешь (ну или ехать придется ооочень долго).

Давайте подытожим, каким проектам нужны юнит тесты:
1. Крупные проекты (5000 часов +)
2. Проекты с большой частотой релизов (CI/CD)
3. Проекты, у которых условия контакта завязаны на количество ошибок

PS Если хотите подробно разобраться в вопросе юнит-тестов, очень рекомендую почитать вот эту статью

Рубрика "Разбор вакансий"

Алгоритм действий по освоению любой профессии:
1. Открыть пару вакансий этой профессии, посмотреть требования;
2. Сопоставить требования со своими возможностями;
3. Отправиться гуглить пробелы.

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

Что я жду от вас
Комментарием к этому посту вы оставляете ссылку на вакансию руководителя проектов.
Стаж, компания, зарплата и т.д. значения не имеют, главное, чтобы это был руководитель проекта.

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

Вам - знания, мне - контент, все в плюсе :)

Вакансия Менеджер проекта 80-100тыс., 1-3 года.

Предисловие
Начну с того, что если вакансия РП стоит меньше, чем 150 - это не чистый РП, а ассистент на выполнение всякой рутины.
Это не плохо, но при условии, что вам нравится проект или сфера проекта (например, вы стартуете в IT).

Разберем требования вакансии

«Координировать команду сервис инженеров»
Внимание! Руководитель проекта руководит проектами, а не сервисными инженерами!
Соответственно документации, этапов и процессов здесь не будет.

«Распределять проектные ресурсы и планировать загрузку»
Обычные задачи РП, обычно они сводятся к ресурсному плану и задачкам в каком нить трекере (но какие задачи могут быть у сервисных инженеров…).

«Составлять календарный план/план работ»
Также нормальная, полезная задача, модно узнать, где они ведут задачи.

«Взаимодействовать с заказчиком и управлять его ожиданиями на всех уровнях ведения проекта»
Никогда менеджеру с зп 100 тыс не дадут контактировать с заказчиком на всех уровнях, к тому же важно, кто этот заказчик (внешний/внутренний)

«Выстраивать процессы на проекте»
Нормальное требование, это также рутина РП

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

Выводы
Во всей вакансии нет ни слова о самом проекте или задачах, которыми предстоит заниматься. Это наталкивает на мысль, что задачи будут максимально не романтичными (скорее всего разгребать заявки обратной связи).
Компания продает принтеры, ничего не производит, скорее всего маленькая и сумбурная.

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

Менеджер IT проектов в КРОК от 3 до 6 лет

Предисловие
На старших курсах Бауманки представители разных компаний хантили студентов на вакансии стажеров. Заманивали рассказами о перспективах и зарплатами (по тем временам около 10-20 тыс).
Представитель КРОК пол часа рассказывал, что у них настоящая спарта и ни о какой оплате не может быть и речи.
Некоторые пошли и не пожалели.
КРОК - это жесткая, но эффективная кузница с огромным арсеналом разнообразных проектов, зачастую из гос. сферы.

Разбор требований
«Участие в проекте со стадии пресейла»
У пресейла есть свои плюсы и минусы (совсем недавно я писал про виды менеджеров, в т.ч. сейла). С одной стороны это весело и разнообразно, с другой очень выматывает и мы никогда не занимаемся реализацией.

«Плотное взаимодействие с заказчиком, выстраивание партнерских отношений и управление ими, совместный поиск оптимальных решений»
Если вы sale manager, то коммуникации - это 80% вашей работы

«Планирование проекта (сроки, бюджет, ресурсы, риски, результаты)»
Зная Крок, с планированием у них должен быть порядок, а значит очень много документов, что в прочем не должно пугать человека, идущего в руководители проектов.

«Управление командой проекта: формирование задач, контроль исполнения»
Это противоречит фразе про участие в проекте на стадии пресейла. Возможно у вас будет свои мини-команда для подготовки бета-версий под пресейлы, а может это требование не является правдой, я бы уточнил на собеседовании.

«Взаимодействие и субподрядными организациями в рамках проектов, выбор субподрядчиков/поставщиков, участие в переговорах, в том числе по получению оптимальной стоимости/ дополнительных скидок, контроль их работы, решение конфликтных ситуаций»
У Крок-а наверняка есть подрядчики на все случаи жизни, поэтому искать их вряд ли придется. А вот управлять подрядчиками наверняка предстоит. Я бы этого не пугался, ругать и подгонять подрядчиков не так уж и сложно.

«Контроль подготовки документации (договора, акты, календарные планы)»
Это Крок, это госы, 100% много бумажек. Из плюсов - также огромное количество шаблонов, аналитиков и тех. писателей в помощь.

Также советую пробежаться пл описанию характеристик успешного кандидата, отлично описывает успешного РП в подобных компаниях.

Выводы
Если вы любите большие стабильные компании со всеми их плюсами и минусами (главный из которых - бюрократия), то Крок для вас.
Если вы только стартуете в своей карьере и хотите кузницу жизни, это тоже туда.
Если вы дорожите свободным временем и нервными клетками, подумайте о стартапах.

Руководитель проектов по цифровизации в Сколково

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

Смотрим требования
«6+ лет опыта в хим. промышленности»
В любой другой ситуации на этом можно было бы закончить, но учитывая, что это Сколково, вероятно там не так все страшно

«Руководство проектами цифровизации от генерации идей и проверки гипотез до создания MVP и внедрения готовых решений»
Читаю, как «мы еще сами не знаем, что делать, нужен сильный коллега, а там разберемся». Если чуть серьезнее, здесь есть MVP и «гипотезы», а значит можно вспомнить про Остервальдера и почитать, чего там делают продуктологи

«Контроллинг внедрений»
Разумеется :)

«Подтверждение эффектов проектов»
«Эффект проекта» звучит, как поствоенный синдром, но ладно, вспомним про важность целей на стадии формирования проекта и что у них д.б. критерии с ориентацией на SMART

«Организация оптимальной поддержки внедренных решений»
Просьба внедрять «оптимальное» решение говорит о том, что критерии достижения целей автору вакансии чужды

«Управление ресурсами (in-house разработка, подрядчики) для получения оптимального результата»
Все понятно, но стоит поинтересоваться, кто эти ресурсы, вероятно подрядчики (если это так, то важно узнать, outstaff или outsource)

От нас ждут:
1. Высшее образование
2. Опыт в цифровизации производственных процессов, он же опыт принуждения людей работать в чуждых для них системах
3. Опыт управления в условиях сильной неопределенности, он же классический быт проектов из Сколково
4. Знание рынка решений для производств Индустрии 4.0: ML/AI, DataScience, IIoT - пришлось немного погуглить и оказалось, что это просто страшные слова (почитайте сами)
5. Agile
6. Свободный английский

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