Мы много раз переживаем этот сценарий, когда сложно взять ответственность на себя и принять решение. Мы всячески пытаемся увернуться и переложить ответственность на другого человека, таким образом защитить себя и свою репутацию. Это естественный ход в случае опасности, а принятие ответственных решений – это всегда опасность.
Недаром говорят – чем выше риск, тем лучше руководитель проектов. Лучшего руководителя проектов ставят на высокие рисковые проекты, там, где уровень ответственности за принятые решения максимально велик.
Что тут можно посоветовать – делайте шаг вперёд, не бойтесь, боритесь со своими страхами и принимайте верные решения.
Легко сказать, учить, писать, чем самому придерживаться данных принципов, но есть один точный и верный совет – действовать.
Как не упустить важные моменты, события? Держать всё в голове? Записывать в блокнот? А что, если событие должно произойти через год, а вам нужно его проконтролировать? Довериться исполнителю, ведь там тоже профессионалы? Это как раз и есть история про то, что в нашей компании все девственники, и каждый раз, как в первый раз. Надеемся, верим, а потом оказывается, что кто-то не уследил, а виноваты не вы.
Именно для таких девственников, как я, и были придуманы календари. Я говорю про электронные календари. Средства напоминания сейчас есть у многих, если не у всех корпоративных мессенджеров. Outlook, Яндекс.Почта, Почта.Mail.ru и другие программы, работающие с электронными письмами – все включают в себя средства напоминания.
Заводите встречи со временем группового обсуждения через год, через два, хоть через столетие, тут важно, чтобы сам сервис напоминаний был устойчивым и не отваливался. Если событие крайне важное – заводите несколько календарей.
У нас есть сервис, отвечающий за работу корпоративного планшета, взаимодействующий с электронной документацией. Продукт платный, а в работу планшета включена лицензия\сертификат. Лицензия выдаётся на период поддержки планшета, обычно срок действия – 365 дней. Через 365 дней сертификат заканчивает своё действие и планшет перестаёт работать. Средств уведомления о том, что сертификат скоро перестанет действовать, в программном обеспечении не зашито. Дату окончания действия можно узнать только через профиль пользователя. Так как с планшетами работают высшие руководящие структуры, то в профиль пользователя обычно редко кто заглядывает – правильнее сказать, что никто не заглядывает.
И мы договорились о правилах. Правила очень простые – это предупреждать заказчика об окончании срока службы действия сертификата за один месяц до его окончания. Так как в самом сервисе уведомлений никаких нет, а доработка стоит денег, и хотя данная задача и стоит в плане работ, но она не является приоритетной и болтается в бэклога со статусом сделаем, когда будет свободное время.
Так вот, чтобы не упустить момент того, когда всем нужно подпрыгнуть и взяться за работу – мы завели следующие правила по напоминаниям по данному сервису. А правило очень простое – есть календарь событий, в который заводится встреча на данное событие на год вперёд, подключаются все необходимые ответственные лица – это руководитель проекта, инженеры, группа разработки. Если есть опасения того, что данный календарь может не сработать, заводятся другие альтернативные календари на данное событие.
Мы все давно уже не девственники, но каждый раз действительно, как в первый раз. Важно решать вопросы не тогда, когда они происходят, а превентивно, с принятием мер заранее. А ещё важнее учиться на чужих ошибках, а не на своих. Вот, делюсь своим опытом.
Ну и если говорить лаконично, то лучший руководитель проектов – это тот человек, который не сидит без дела, а постоянно находится в «движе», постоянно делает шаги вперёд, постоянно тянет за собой свою команду и развивает свою компанию. Больше активности, друзья.
Глава 15. Автоматизация хаоса.
Мы живём в мире информационных технологий, где школьников уже в третьем классе учат собирать роботов и писать чат ботов. Это очень круто. И многие настолько захвачены и поглощены этой парадигмой – «даже школьники могут, так почему у нас этого ещё нет», что пробуют прикрутить знания по роботизации и автоматизации ко всем процессам компании. При этом все мы забываем, что автоматизировать нужно и важно то, что мы каждый день 133 раза делаем руками. Вот если вы сами руками проходите по одному и тому же маршруту и сделали это уже 10 000 раз, то такой процесс можно автоматизировать. Если у вас есть уверенность в том, что данный процесс в 99% случаев отрабатывает корректно, и каждый раз всё происходит однотипно – это автоматизировать нужно. Если процесс периодический, не протестированный, если есть только желание автоматизировать, но нет усердного прохождения по маршруту в количестве 10 000 раз – это автоматизации хаоса. Вы создаёте автоматизированный процесс, который не улучшает, а ухудшает работу пользователей Системы.
Сколько раз мы проходили по одной и той же истории – давайте это автоматизируем. Начинаем автоматизировать, проходим по стандартному сценарию, всё работает отлично – передаем заказчику с инструкцией по применению.
Как вы думаете, что происходит дальше? Ну в общем, практически всегда одна и та же история – ваш продукт некачественный, Система работает нестабильно, верните нам деньги за предоставленные услуги, ваша работа не профессиональна.
Начинаем разбираться, подключается высшее руководство, почему всё получилось так, как получилось?
Ответ один – автоматизация хаоса.
Безусловно, что руководство такой ответ не устраивает.
– Лёша, ты отвечаешь за все процессы. Ты руководитель проекта, и тебя брали для того, чтобы заказчик был доволен, – кричит мне директор, вымещая на мне всю злобу и ненависть.
Отступление. Может показаться, что директор плохой, негодяй, и прочее – нет. Директор такой, какой есть, и мне директора не изменить.
Получается, что ситуацию нужно исправлять, и сделать это сейчас гораздо сложнее, чем могло бы быть сделано ранее.
Автоматизация уже проведена, часть процессов успешно работает, но вот часть очень важных почему-то даёт сбой. Что делать? Откатываться? В общем ответ очевиден – да, откатываться. Но вот только времени уже прошло немало с момента обновления, и многие пользователи уже привыкли к автоматическим процессам. Руководство настаивает на своём – исправляйте уже существующие процессы автоматизации, выпускайте багфикс. Мы начинаем исправлять автоматизированный хаос.
Может показаться, что я вам описал ситуацию применительно только к нашей Системе. На самом деле – это распространённая практика. Поэтому, если кто-то из умников предлагает вам что-то автоматизировать – 100 раз подумайте и 1000 раз протестируйте.
В школе прикладного каратэ есть философия – если хочешь, чтобы удар стал твоим, ты должен отработать его 10 000 раз. В программировании, в IT, философия такая же – если хочешь, чтобы автоматизация была успешной, пройди процесс 10 000 раз.
Ну а в целом, автоматизация – это круто.
Тестируйте больше, прогоняйте по сценариям, отрабатывайте свой один удар автоматизации.
Осу!
Глава 16. В сухом остатке.
Многие начинающие руководители для того, чтобы показать суть проблемы, рассказать про вопросы улучшений по ситуации, ударяются в полемические тезисы. В описании ситуаций мы добавляем много красноречивых, художественных, литературных оборотов, своих или чужих эмоций – это неправильно.
Лучший руководитель проектов говорит лаконично, чётко, по делу, по существу.
Эта глава про то, как научиться выражать свои мысли в письмах, диалогах, презентациях, выступлениях, переговорах, и чётко описывать ситуацию. Краткость – это сестра таланта, и данная глава про то, как отвечать по существу.
Данная книга – это хронология моей жизни с ошибками, неудачами, промахами и опытом. Опыт – это самое главное, о чём и хочется рассказать\написать.
Я не буду здесь описывать свои ошибки, скажу лишь кратко – раньше я очень часто и много в деловой переписке добавлял художественных оборотов, эмоций, восклицательных и вопросительных знаков. Сейчас я тоже использую данные обороты, но в минимальном объёме и по существу. Вот мой опыт.
Сейчас моя политика в отношении статусов кардинально поменялась. Никому не интересно читать длинные и художественные речевые обороты. Деепричастные обороты в предложениях разрушают мозг высшему руководству. По факту все люди одинаковые. Статус должен быть конкретным, быстрым, лаконичным – все хотят чётко и по существу. Самый лучший вариант статуса – это да или нет, и немного деталей по существу.
Мой руководитель часто задаёт мне вопрос – Лёша, по итогу, что в сухом остатке?
Ну а дальше мой опыт про то, как этот сухой остаток получить.
Как показывает практика – писать\выражать свои мысли лаконично – это не самая простая задача. Как несколькими словами\предложениями описать текущий статус без дополнительных деталей? Как донести до заказчика или руководителя всё то, что вы пережили, и как решили вопрос? Сухой остаток – это не самая простая история в работе руководителя, но мы с вами, лучшие руководители проектов, должны уметь это делать.
Первое, с чего нужно начать при подготовке сухого остатка – это максимально детализировано собрать всю информацию по процессу, по проблемам, по решениям и по итогу.
Всё это нужно собрать, разложить по полочкам, оформить в хронологическом порядке, распределить по ролям.
По итогу у вас должен получиться небольшой рассказ. На первом этапе не возбраняются художественные и литературные обороты, деепричастные обороты, сложные предложения, максимальная детализация. Всё, что вы хотите включить в свой рассказ – смело включайте. Ваш задача – максимально детализировано описать все события. Не возбраняется эмоциональная составляющая, нецензурная речь. Хотя, впрочем, нецензурную речь всё же лучше не включать. В общем, вам нужно написать всё так, как было и происходило.
Итак, рассказ написан – первый этап подготовки сухого остатка завершён. Теперь выкладывайте свой рассказ в чат, в топик коммуникации со своим подразделением\командой и попросите, чтобы ребята подтвердили, всё ли верно вы описали или есть какие-то замечания. Скорее всего коллеги могут и сразу согласиться, и могут добавить какие-то детали, возможно важные, а возможно и нет – их тоже включайте в свой рассказ.
У вас должно получиться произведение на произвольную тему в формате сочинения\изложения происходящих событий, в котором возможны художественные обороты речи и деепричастные обороты.
Переходим ко второму этапу. На втором этапе наша задача, убрать как можно больше слов, сохраняя при этом суть своего изложения. Чем меньше объем – тем лучше.
Возможно, что на этом этапе у вас будет непреодолимое желание оставить какое-то предложение, как есть, потому что оно очень ярко описывает сущность происходящего. На этом этапе можно побороться со своим желанием и удалить художественной оборот, но если желание превыше вашего душевного равновесия – можете оставить.
Ваша работа должна быть выражена в жёсткой корректуре ранее написанного текста. Представьте, что вы редактор политической газеты, в которой недопустимо отражение эмоционального подтекста, очерняющего высоту полёта вашей партии. В общем, вычеркивайте и убирайте всё, что только можно убрать.
Итак, мы подошли к третьему этапу. Постараемся здесь поставить точку, но не переживайте, возможно у нас будет ещё и четвёртый этап. На третьем этапе мы ещё раз вычитываем ранее написанное. Удаляем всё, что дрогнула рука удалить на втором этапе, меняем местами предложения, меняем местами слова, расставляем запятые, тире, точки, переносы строк. Постарайтесь, чтобы текст выглядел лаконично, лучше всего, если это будет текст в формате маркированного списка.
Таким образом, в сухом остатке у вас получится лаконичный и структурированный рассказ. Ещё раз перечитайте его, если увидите слова, которые можно удалить и без которых смысл изложения не потеряется – смело удаляйте их.
В сухом остатке – пишите, сокращайте, структурируйте. Чем короче описание событий проблемы, тем удобнее читать и вникать в суть проблемы. Для руководства важно быстро вникать в суть без погружения в детали – это и есть то, что называется «в сухом остатке».
Может показаться, что три, четыре этапа можно сразу сократить до одного и с ходу писать так, чтобы получалось в сухом остатке. Да, можно. Когда вы научитесь такому стилю изложения, возможно, ваши труды будут ставить на одну полку с великими писателями. Ведь даже великие писатели помногу раз переписывают для того, чтобы достичь великолепия изложения. Одним словом, выразить то, на что уходит несколько предложений – это великое искусство, великий дар.
Резюмируя всё и изложенное выше, хочу заметить, что следуя данной практике, мне удалось достичь успеха в отражении текущего статуса для руководства, коллег, заказчиков, пользователей.
Конечно, мне хочется писать сразу и набело, но это очень сложно. У меня так не получается. Свои тексты я сначала прогоняю сам по этапам номер один, два, три, а потом отдаю на согласование своему руководителю или корректору\редактору текстов Гульмире. Одно могу сказать точно – не скупитесь на слова, пишите, описывайте, рассказывайте, формулируйте свои мысли в слова. Чем больше вы пишете, тем больше у вас опыта и практики. Лучший руководитель проектов – это тот, который с первого раза может написать так, что ему позавидует великий писатель.
Пишите, переписывайте, сокращайте.
Глава 17. Банально.
Есть такие слова, не то чтобы это слова паразиты, нет. Это слова, описывающие великую простоту решения по длинному развитию ситуации.
Одним из таких слов является слово – «банально».
Не скажу, что употребление данного слова является табу, и его ни в коем случае нельзя употреблять – нет. Замечу только, что это мнение, как и все другие мысли решения в книге, является личным мнением автора.
Нет ни хорошего, ни плохого, есть просто моменты, на которые обращают внимание, и здесь только мой опыт, и моё видение мира. Вы вправе соглашаться или не соглашаться. Моя задача —описание ситуаций и решение выхода из этих ситуаций. Выход может быть не только один, их может быть великое множество. И тут уж каждый сам выбирает, какое решение и какой выход ему нужно выбрать.
Итак, слово «банально». Употребление этого слова, впрочем, как и слова «просто», является нецелесообразным в описании решения нетривиальных ситуаций.
У меня есть инженер, который практически для любого решения использует слово «банально». И я уже перестал его спрашивать, почему, если всё так банально – мы не решили ситуацию сразу, заблаговременно и оперативно? Почему сейчас к решению ситуации приходится подключаться руководству, если всё так банально? На этом обычно наш диалог заканчивается, и инженер идёт выполнять банальные действия.
Почему я против употребления этого слова? Ну потому что обычно использование слова «банально», в контексте с развитием решения ситуации, приводит к дополнительным скандалам и эскалациям.
О чём речь? Ну вот вы говорите заказчику: «Мы всё исправили». Заказчик вас спрашивает: «А в чём была проблема?». А вы ему отвечаете: «Ну, мы банально поменяли\внесли изменения в настройки». Заказчик вам в ответ – если всё так банально, почему ситуация не была решена превентивными мерами? Вот поэтому и важно перестать использовать такие слова, как банально, просто.
Я не говорю о том, что нужно рассказывать, как сложно вам далось решение, но у заказчика должно остаться такое чувство, что он не зря вам платит те деньги, которые платит. Было решение, ради которого не нужно жалеть потраченных денег. Это не какая-то банальная история, это серьёзная работа профессионалов в области своего дела.
Эта глава о том, что важно рассказывать, объяснять, детализировать, выпускать и переписывать инструкции, обновлять информацию, не скупитесь на решения, не упрощайте дело рук своих. Помните о том, что для профессионала легко и банально, для стороннего наблюдателя – это сложная и кропотливая работа. Рассказывайте о сложной и кропотливый работе. Рассказывайте о сделанных шагах, рассказывайте о принятых мерах, которые не должны привести к повторению сбойной ситуации. Не усложняйте, но и не говорите о том, что всё банально.
Не будьте банальны и просты.
Глава 18. У нас болванчиков хватает.
Важно делать, а не говорить.
– Лёша, у нас болванчиков хватает, – высказался директор в гневном порыве авторитарного диктата компании.
У меня болванчик ассоциируется с игрушкой неваляшкой времён СССР, знаете, такая кукла, которая состоит из трёх шаров разного диаметра.
Маленький шар – это голова. Средний шар – это талия. И большой шар – туловище\основание.
И вот как бы ты эту куклу не раскачивал, не пытался уронить, она не падает, устойчиво качается, кивает, издаёт урчащие звуки, и ты успокаиваешься. Ну, не ты конечно, а ребёнок. Это обычная физика – в основании туловища встроен тяжелый шар, который не дает шарам меньшего диаметра перевесить основание куклы.
В простонародье – это кукла-неваляшка. По подобному принципу сделана другая кукла под названием «болванчик».
У болванчика на шарнире к основанию туловища прикреплена голова, обычно сделанная вытянутой, овальной формы.
Вот, значит ты делаешь толчок головы такого болванчика, и он длительное время головой кивает, как бы соглашаясь с тобой.
Работа руководителя неизменно связана с проектными встречами, переговорами, принятием сложных и, порой, очень сложных руководящих решений.
Просто покивать головой на совещании – это неплохой манёвр для руководителя низшего звена, но для лучшего руководителя проектов – важно не только кивать, но и делать.
Лучший руководитель проектов – это проектный лидер. Это человек, который принимает сложные и нетривиальные решения. Лучший руководитель технической поддержки, лучший руководитель проектов, просто лучший руководитель – должен уметь отстаивать интересы компании, заказчика, клиентов, сотрудников, коллектива, команды. Здесь просто покивать, покопипастить и переслать не получится.
– У нас болванчиков хватает, Лёша, – говорит мне директор.
Директор понимает, о чём он говорит. Копипастить и транслировать – это не то, чего от меня ожидает начальник. Домыслить, докрутить, преобразовать, поменять, улучшить, решить, заработать денег и принести их в компанию, в команду – этого ждёт от меня большой босс.
Быть руководителем непросто. Быть лучшим руководителем – это совсем непросто.
Резюмируя и подводя итоги данной главы, скажу одно – меняйте и улучшайте все тексты, которые к вам приходят, подстраивайте их под свои процессы и привносите улучшения.
Глава 19. В каждой избушке – свои погремушки.
В каждом монастыре свои правила.
Ну, в общем да, если перефразировать – то однозначно – в чужой монастырь со своим уставом не ходят.
Эта глава про то, что к каждому заказчику, к каждому клиенту, к каждому пользователю у вас должен быть свой подход. Начинать конечно нужно с контрактного договора, с его изучения, затем —общение с заказчиком, с ребятами, которые делают сервис с другой стороны.
Про договор я уже рассказывал, тем не менее расскажу ещё раз, так как договор является основополагающим документом, в рамках которого осуществляется взаимодействие.
Вы должны хорошо\очень хорошо изучить контрактный договор – практически выучить его наизусть. Обычно к контрактному договору прикладываются\прилагаются технические задания, а возможно и другие разнообразные приложения. Вот вся эта документация должна быть досконально изучена руководителем проекта.
Договор, хотя и является основным контрактным документом, но если у вас нет\не налажено коммуникационное взаимодействие с заказчиком, если не налажен контакт, если вас в любую минуту могут подставить – вас подставят. Договор помехой не станет, поэтому в этой главе мы будем говорить про неформальное взаимодействие с заказчиком.
Конец ознакомительного фрагмента.
Текст предоставлен ООО «Литрес».
Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.
