Контроль полезных привычек

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

На самом деле не так важно "не пропустить эти два дня" – у всех есть выходные или просто плохие дни.

И это не имеет никакого отношения к мотивации.
Как отвечал Артемий
- Как мотивировать себя что-то делать?
- Да никак, оставайтесь в жопе!

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

Стоит развивать тему продуктивности или все и так всё знают?)

Оценка времени выполнения задачи по PERT

PERT (Program Evaluation and Review Technique) - это методология планирования для сложных проектов с большой неопределенностью.

В этой методологии описан метод оценки по трем точкам.

Для «сложной» задачи предлагается дать три оценки:

- оптимистичную (А)
- пессимистичную (В)
- наиболее вероятную (С).

Оценка = (А+В+4*С)/6
Т.е. опыт решает

Выводы:

1. Метод полезен тогда, когда нужно оценить что-то сложное и непонятное
2. Задумываясь над пессимистичной оценкой, вы подумаете о рисках
3. Вы получаете обоснованную оценку, которую проще защитить перед заказчиком

Новости канала

Друзья, всем доброго времени суток!

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

Времени на посты станет меньше, но сдаваться я не намерен и планирую продолжить делиться опытом и знаниями минимум трижды в неделю.

Этим постом я хочу попросить вас об обратной связи - о чем вам нравится читать?

Напиши, пожалуйста, в комментарий или просто проголосуйте чуть ниже.

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

Вопрос от студента: "где сегодня вести задачи, если 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 Если хотите подробно разобраться в вопросе юнит-тестов, очень рекомендую почитать вот эту статью