МЕНЕДЖЕР ПРОЕКТА БЕЗ ТЕХНИЧЕСКОГО ОПЫТА

Карьерный вопрос от Михаила @dulitman

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

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

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

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

Теперь к сути вопроса – а можно ли стать ПМом без технического опыта? ПМ – уровень линейного руководителя, который находится очень близко к людям, ставит им конкретные задачи, принимает результаты. Иногда, даже подхватывает сам какую-то работу. Например, зарегрессить что-нибудь перед релизом. Или контент загрузить. Можно ли все это делать без хорошего понимания технички? Увы. Делать-то можно, но хорошо не получится.

А теперь главное НО. Уровень погружения в ПМа в технику - это не rocket science. Вот совсем нет. Базовый уровень технической грамотности, некоторые нюансы конкретного проекта. Код тут писать не надо. Даже читать не надо. Надо понимать, что инженеры говорят. Все это прокачивается. Нужно время и много-много желания для этого. Но все достижимо. И таких примеров у меня, повторюсь, перед глазами было много.

Один мой близкий товарищ пришел из нефтянки. Спустя месяц он уже круто ориентировался в проекте, который ему дали. А к концу испытательного срока ничем не уступал ПМам, которые всю свою карьеру провели в родимой IT-шечке. Научился, прокачался.

Мир IT большой, компаний и проектов много. Выбирайте на старте что-то попроще (вплоть до сайтов на движках, например), выделяйте силы и время на саморазвитие, и двигайтесь плавно к более сложным проектам и более сложным позициям ПМ. И все получится!

Надеюсь, получилось ответить на вопрос.

ВОПРОС В ЗАЛ

Друзья, привет!

Эта неделя обещает быть активнее предыдущей. И я хочу попробовать новый формат. Я задам вам вопрос, а вы делитесь мыслями в комментариях. Пообсуждаем, поищем истину вместе. В конце недели расскажу свою историю по этому поводу, посмотрим, насколько мы сходимся во взглядах 🙂

А вопрос следующий:
Как воспитывать в сотрудниках ответственность?

Порой это прям массовая проблема, на всю компанию. Ну не сделал фичу вовремя, и ладно. Ну не закрыли в спринт все, что планировали, и ладно, передвинем в следующий. Ну не отгрузили поставку заказчику и он теперь бабки теряет, и ладно. И т д и т п, на разных уровнях. Хорошо, если хоть ТОПы бегают. А то, бывает, вообще один СЕО разгребает.

Тут нужна трансформация прямо в культурном коде уже. И вот как это делать?

Делитесь своими решениями! У кого были такие задачи, как удавалось побеждать?

ПРО ТОКСИЧНОСТЬ

Друзья, а что вы думаете про токсичность? Плохо это? Или хорошо?

Как по мне, токсичность в команде, это как лампочка “Check Engine” в машине. Да, неприятно, когда она горит. Бесит прямо даже. Но пусть лучше загорается вовремя, пока я еще могу ехать. И если долго ее игнорировать, то двигателю хана. И с командой точно также.

Разбираться с токсичностью самой по себе – не имеет никакого смысла. Это всегда следствие чего-то. Личных проблем человека, например. Или проблем процессов и командообразования. Или конкретных межличностных отношений. Много вариантов.

Поэтому крайне важно докопаться до сути. Лечить симптомы – не очень эффективно. Да и как их лечить то? Отругать? Премии лишить? Уволить? Как-то нет хороших методов в арсенале.

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

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

Может быть, что это межличностная токсичность. Не любит конкретный Петя конкретного Васю. Причем взаимно. Хуже, когда Вася – это вы, а Петя – ваш сотрудник. Но и здесь рецепт примерно такой же. Обсудить, объяснить по-взрослому, что так работать не пойдет, и либо учимся конструктиву, либо кому-то придется компанию покинуть. Здесь в загашнике может быть классный вариант с ротацией – сменить одному из них команду или проект, минимизировать негативные отношения. Если с причиной не ошиблись, то все исправится. Есть прям целый парад таких кейсов в опыте.

Ну и, наконец, часто под токсичностью маскируются проблемы команды и процессов в ней. Об этом великолепно описал Ленсиони в своих “5 пороках команд”. Рекомендую. Путь решений также можно выстроить по Ленсиони – идем по пирамиде снизу вверх, закрываем порок за пороком. И так, пока не искореним эту самую токсичность.

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

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

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

А как вы работаете с токсичными кейсами?

БИГ-БОССЫ И ИХ РАДАРЫ

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

Вопрос:
Подходит к концу испытательный срок. Отношения с руководителем получилось выстроить, все ок. Каких-то взаимодействий с начальником +1 уровня не было, и пока не предвидится.

Для того чтобы развиваться дальше по карьере в этой компании, очевидно, нужно как-то начать работать с +1, +2 и выше, чтобы попасть к ним на радары, как-то зарекомендовать себя. Как сделать это экологично?

Ответ:
Поскольку инициативы от самого руководителя уровня +1 не поступает, ждать ее и не следует. Надо брать все в свои руки 🙂

Можно решать задачу в лоб – попросить тет-а-тет с +1 руководителем, обсудить с ним свои желания, договориться о совместной работе и о каких-то задачах. Будет ли это хорошо? Скорее всего, нет. Потому как ваш непосредственный руководитель может отреагировать не совсем благосклонно, оценить это, как прыжок через голову. Итого можно благими намерениями испортить себе важные рабочие отношения. Может быть, даже самые важные. На текущем этапе.

Как тогда? Я бы в таких случаях посоветовал идти через запрос о развитии. Прийти к своему непосредственному руководителю, объяснить ему, что хочется дальше расти и развиваться в компании, попросить помощи, менторинга и плана развития. Нормальный руководитель не должен расстроится. Даже наоборот. Кадровый резерв подрастает, который еще и сам с инициативой. Потом хоть в отпуск, хоть на больничный, хоть просто полениться можно будет. Кайф же!

Важно! Непосредственный руководитель может отреагировать иначе. Почувствовать угрозу. Закрыться. И тогда ничего у вас не выйдет. Совсем. Но тогда стоит и осознать, что роста в компании у вас не будет, во всяком случае, при этом начальнике. И тогда надо ли оно вам вообще тут надолго задерживаться? Почитайте по этому поводу Литвака, очень круто расписывает эту тему.

Если ваш руководитель, скорее, карьерист (по Литваку), то он охотно включится в эту игру. Вы получите план развития, цели и задачи. А во имя их воплощения будете получать что-то от начальника, что-нибудь он вам обязательно будет делегировать из своего, чтобы научиться. И такие вот задачи – как раз то, что вам нужно. Он же свое отдает. А он взаимодействует уже в других кругах, с этими самыми +1, +2, +N уровнями. И будет у вас классная и легитимная возможность поработать с ними, показать себя, на других посмотреть. Ну и на радары нужные попасть, чтобы расти и дальше по карьере.

P.S.
Если вам тоже нужна консультация или менторинг, пишите мне в личку @ilya_prakht и мы договоримся!

А если хотите получить бесплатную консультацию, то задавайте свой вопрос в форму

ПРО ОТВЕТСТВЕННОСТЬ

По мотивам вот этого вот поста. Вы накидали целую кучу классных идей и вариантов. Во многом, это совпало с моим видением. Было несколько неожиданных идей, которые я забрал себе 🙂

А теперь, как и обещал, поделюсь своей историей и своими мыслями.

Говоря об ответственности, о безответственных сотрудниках, о необходимости передачи ответственности, все время вспоминаются классические 4 причины. И не зря. Реально, инструмент сюда подходит, как нельзя прекрасно.

Человек делает что-то не так или не делает что-то (в нашем случае не берет на себя нужную нам ответственность) по 4 потенциальным причинам:
1. Не понимает
2. Не умеет
3. Не может
4. Не хочет

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

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

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

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

Не умеет. Казалось бы, что может быть проще: берешь ответственность и несешь ее. Но не тут то было. Если концептуально все вроде бы понятно, то на уровне конкретных действий – не очень. Вот закрыли мы спринт не полностью. Что делать? Как это все правильно обрисовать руководству? По шапке же тоже неохота.

А еще бывает, что руководитель сам, как мама-утка, все за своими сотрудниками прибирает и всю ответственность на себя сгребает. Случилась проблема – схватился и сам все решил. Делегировать надо. И обезьянок на спину возвращать. Условно, накосячил – исправляй, сам.

Отсюда решение по пункту Не умеет – делегировать ответственность, показывать своим личным примером, как надо, спрашивать за результаты. Про это тоже писали, довольно много.

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

ПРО ОТВЕТСТВЕННОСТЬ #2

Продолжение.

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

Мы потом его спросили, почему он так сосредоточен на проекте, а по сторонам не смотрит. И все подтвердилось. Он бы и рад, но первоочередной спрос с него – за результаты команды. А остальное – уже как повезет. Получается, чтобы где-то прибыло, надо, чтобы где-то убыло.

Отсюда решение по пункту Не может – давать ресурсы, расставлять правильные приоритеты, давать возможность для этой ответственности. Было и про это в ваших комментариях.

Не хочет. Ну и в завершении, для полноты картины. Был в комментариях логичный вопрос – “а почему должен?” И действительно. Что мы такого сделали для сотрудника, чтоб он взваливал на себя больше, чем было. Или чем ему комфортно. Тут уж зависит от ситуации. Понятие ответственности идет под руку с понятием мотивации. Есть мотивация – будет и ответственность. А если нет одного, то не будет и другого.

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

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

Итого получается следующий рецепт: понятные ожидания + полноценное делегирование и личный пример + ресурсы и приоритеты + правильная мотивация. Где-то нужен один пункт, где-то парочка, а где-то сразу все. Используйте, как чеклист.

Друзья!

Возвращаюсь после длительного перерыва. И эта неделя обещает быть богатой на контент 🙂

Начнем с анонса. В эту среду, 24 апреля, в 15.00 мск проведем эфир вместе с Сашей Орловым, где поговорим о роли Руководителя Отдела (менеджера менеджеров), его компетенциях, полезных инструментах. И покажем курс Стратоплана, который таких РО готовит.

Мероприятие бесплатное. Регистрируйтесь и приходите!

Сделали на канале "ВТБ для бизнеса" небольшую шпаргалку про DISC, особенности разных психотипов, подходы к контролю и управлению.
Полезное

УПРАВЛЕНИЕ РИСКАМИ В КОМПАНИИ

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

Как управлять рисками на проектах, в целом, понятно. PMBOK нам все про это рассказал: идентифицируем, оцениваем, приоритезируем, митигируем. Дальше контролируем. А как работать с рисками на уровне всей компании?

Во-первых, есть специальные стандарты. Их очень много. Есть общие и универсальные. Есть локальные. Есть специфические для отрасли, например, целая куча стандартов есть в банкинге. Наиболее интересные и популярные:

- ISO 31000
- FERMA
- COSO
- …

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

Во-вторых, есть совершенно классная модель “3 линий защиты”. Как понятно из названия, мы делаем 3 уровня работы с рисками:

1. Уровень функций – реализуется в каждом подразделении, выполняется мониторинг, контроль и реагирование на риски. Например, тимлид следит за исполнением требований ИБ своими сотрудниками.

2. Уровень мониторинга – специальные подразделения, которые определяют базовый набор рисков, формируют инструкции и регламенты по работе с ними, разбираются в каких-то нестандартных ситуациях и следят, чтобы процессы риск-менеджмента работали правильно во всех отделах. Например, все то же подразделение ИБ, комплаенс, юристы и т д.

3. Уровень внутреннего аудита – какой-то орган, чаще всего комитет, реже – прям выделенное подразделение, которое оценивает общее качество риск-менеджмента в компании, постоянно адаптирует процессы под стратегию компании. Например, изменение политик ИБ, если появились изменения ФСТЭК.

Чем интересен подход? Как по мне, он хорошо определяет не только управление рисками, но и общую методологию построения процессов в любой компании и любом отделе. Чтобы все работало, нужно 3 вещи:

1. Люди или команды, которые выполняют работу согласно процессу

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

3. Дополнительный механизм пересмотра работы процесса и его согласованности с текущей реальностью

Вспоминаю, как мы внедряли Scrum. Тимлиды на местах и команды реализовывали фреймворк. Delivery Manager-ы определяли, как адаптировать Scrum к проекту, как его внедрять и как мониторить потом. Ну а топ-менеджмент давал добро или недобро на всякие изменения, когда того требовали новые цели компании или конкретный проект не мог раскатать тот процесс, который был нужен нам. Эдакие “3 линии внедрения Scrum”. Интересно 🙂

Вот такие мысли. И такие инструменты. Надеюсь, будет полезно.

Видео вчерашнего Openday Стратоплана "Руководитель отдела: Смена декораций в управлении людьми"

https://youtu.be/aONzCVfgxGo

Я тут поучаствовал в одной коллаборации. Полезной, как по мне. Ребята собрали в общую папку ProБизнес несколько авторских каналов (именно авторских, это важно), где люди пишут про менеджмент (как я), про стратегию, про ведение бизнеса. Есть что почитать.

Посмотрите, вдруг и вам что-то будет полезно.

Что внутри?
✅ авторские экспертные каналы
✅ личный опыт, инсайты и кейсы
✅ свежие идеи и лайфхаки
✅ море пользы и вдохновения

Подписывайтесь на папку ProБизнес и забирайте все, чем делятся коллеги. Можно подписаться на все каналы сразу или выбрать самые интересные для себя.

И еще один анонс!

Уже завтра, 26 апреля, в 20.00 мск проведу открытый урок курса Delivery Manager в OTUS "Слон на нитке – реально ли управлять тимлидами и как это делать?".

Поговорим об инструментах управления тимлидами и роли DM во всем этом.

Присоединяйтесь

КАК ПОДРУЖИТЬ DISCOVERY И DELIVERY

Конфликт интересов Discovery и Delivery – тема классическая и распространенная. Круче и чаще только конфликт “Продажи vs Производство”. Почему так?

Оба эти этапа, и Discovery, и Delivery, находятся последовательно в одной цепочке производства ценности. И, стало быть, очень сильно зависят друг от друга.

Проработали требования плохо – Delivery делает не то, потом приходится долго и муторно переделывать. Проработали очень подробно – Delivery счастливо, но зато и времени уходит непростительно много. А если нам нужно быстро протестировать, скажем, пачку гипотез, то это совсем непростительная роскошь.

Есть еще распространенная фишка, поставить каждому из них свой KPI на Lead Time. И тогда Discovery, лишь бы сделать что-нибудь, отдает побыстрее сырой материал в разработку, а Delivery, понимая все риски для своего Lead Time, долго и нудно не принимает требования и постоянно возвращает обратно в Discovery. Вот так и живем.

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

Как быть? Как по мне, нужно сделать 2 вещи:

1. Формализовать процесс передачи продукта из Discovery в Delivery. Какие-то чеклисты, четкие Definition of Done и т д. Чтобы однозначно было понятно, как должна выглядеть документация и проработка требований, чтобы разработка могла начать ими заниматься

2. Добавить командам какой-то общей мотивации. Внедрить общий KPI. Например, пусть вместе гонятся за единым T2M (Time To Market). Тогда не до ругачек на стыке, иначе премия у всех погорит. При этом, их собственные KPI на Lead Time тоже можно оставить, но мотивацию на них сделать ниже, чем на общий результат. Например, делить премию 30/70 за свои/общие KPI

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

Ну например, ссорятся все время Вася с Петей, когда Вася делает пулреквест, а Петя потом его на ревью заваливает некритичными замечаниями. Если отсыпать Пети мотивации на достижение хорошего Lead Time Васей, то он перестанет придираться по мелочам, а будет выделять только реальные и критичные проблемы. А если закрепить это все четкой инструкцией, то такая схема обречена на успех.

Или зависают разработчик и QA на тестировании. Один постоянно сажает мелкие баги, а второй старается как можно больше таких найти, вплоть до пиксельперфектов, до которых никому нет дела. Ну такой вот ему KPI придумали, чем больше багов, тем лучше работа. Добавляем обоим общую мотивацию на сдачу релиза вовремя, регламентируем правила заведения дефектов – и проблема уходит.

Что скажете? Согласны с такой идеей? Какие еще есть варианты?

JOB SECURITY

На одном интервью меня спросили: “какой ваш главный факап, как руководителя?” Задумался. Если не отделять себя от компании в моменте, то есть что вспомнить. Не успели разогнать продажи к дедлайну. Не получилось продать правильную стратегию CEO. Не удержал важнейшего сотрудника. И т д и т п. У каждого менеджера есть толстый блокнот с факапами, такое “кладбище решений”. И чем толще блокнот, тем лучше будет менеджер, как по мне.

Но это все, что называется, “вжившись в роль”. А есть ли что-то, если отделить себя от конкретной компании? Как наемный менеджер, сам по себе. И тут я понял, что такое есть, и ответ для меня однозначный: не следил за Job Security.

Что такое этот ваш Job Security? Если упростить, то ваша уверенность, что лишившись конкретной текущей работы, вы все еще окажетесь нужны рынку. И у этого понятия есть несколько составляющих:

1. Количество похожих вакансий – для программистов это десятки тысяч, для тимлидов тысячи, для EM и DM это уже сотни, для СТО десятки

2. Среднерыночный уровень ЗП – вы классный на своем месте и вам часто готовы платить много, просто потому что вы классный на своем месте, а если место поменяется, то вы уже не так уж и нужны, поэтому начинают предлагать что-то средненькое на рынке

3. Соответствие вас, как профессионала, среднему портрету кандидата в вакансиях – и тут рынок все выравнивает, хоть и есть много уникальных позиций

Так вот, оглядываясь назад, понимаешь, что полезная штука этот Job Security. И надо за ним следить. Я вот не следил, последние лет 5 до прошлого года. Не смотрел вакансии, не ходил по собеседованиям, мало общался с ЛПРами. Сам много нанимал, уровень ЗП знал, потому что мы регулярно такую аналитику заказывали. Но на этом и все.

Собрал тут несколько полезных советов, по мотивам своей рефлексии. Забирайте, кому пригодится, и добавляйте свои идеи в комментарии:

1. Регулярно следить за вакансиями на вашу позицию. Чтобы понимать требования к кандидатам, уровень ЗП, тренды в найме и т п

2. Ходить на собеседования. Даже если не собираетесь увольняться. Даже если вы менеджер. Вот тут много холиваров на этот счет, но моя простреленная нога говорит мне, что ходить надо

3. Нетворкаться и развивать свою сеть знакомств. И обязательно иметь там хороших рекрутеров, желательно специализирующихся на позициях вашего уровня. Как минимум, они владеют невероятным объемом нужной вам информации в моменте

4. Развивать свой бренд. Не надо здесь упарываться, но 1-2 раза в год можно что-нибудь интересное рассказать. Отлично работает и для понимания, что нужно рынку, и для развития нетворкинга. Да и могут на собес куда-то пригласить

5. Развивать себя. Не застревать в рамках той роли и той компании, где вы сейчас. Смотреть по сторонам и постоянно подтягивать то, что рынок просит

6. Иметь план Б. В любой момент “скрипач может оказаться не нужен”. И вы должны быть к такому готовы. И морально, и материально. Мой лучший рецепт здесь – диверсификация, всего и вся

7. Всегда помнить, что вы наемный сотрудник. В нашей культуре сильно развит патриотический тип мотивации. И занимая высокую позицию, порой, кажется, что вы “уже часть корабля”. Но это не так. Вы все также наемный сотрудник, которого взяли под конкретные задачи и конкретные условия. И это легко может поменяться, такова жизнь. Важно быть патриотом компании и проявлять лояльность к ней. Но не менее важно быть патриотом самого себя, и проявлять лояльность к самому себе. Вот мой факап был как раз тут

Это мой список. Субъективный, не всем подходящий. Но реально прожитый.

А вы пишите, что еще сюда можно добавить!

P.S. А еще мы тут со Стратопланом запилили целую конфу про фейлы и факапы. 11 мая, в субботу. Я в этот раз не уместился, поэтому излил душу сюда вам 🙂 Но рекомендую!