"Оцени результат" (бывают ли проекты "неуспешными"?)

Очень часто читаешь в различных обзорах про "% проваленных проектов".
И как-то очень хочется поинтересоваться - "а всех ли участников проекта" опросили? И точно со всеми поговорили об истинных целях, которые они преследовали приходя в проект(или затевая его) .

В качестве примера приведу собственный опыт (это был мой первый проект в жизни).
Я пришел в компанию региональным менеджером по продажам. Но меня через 2 недели вызвал владелец и мне было предложено заниматься "более актульным и, на их взгляд, подходящим мне" - проектом вывода на рынок нового продукта под их торговой маркой.
Не буду описывать мой тогдашний шок от такого предложения. Не буду рассказывать обо всем, что произошло в самом проекте. Главное - что получилось в результате.
А в результате проект длился 4 месяца (если я все правильно помню). И был закрыт владельцем компании.
Перед этим владелец компании вызвал меня и "предложил" отчитаться о проекте.
Я был полностью уверен, что проект провален (и был провальным изначально). Просто как совсем "молодой специалист" в области PM я этого сразу не мог определить.
При разговоре с владельцем я сначала попытался рассказать о том, что все вроде бы неплохо (мы к тому времени почти "вышли в ноль"). Но он перебил (возможно, отчасти и видя мое кислое лицо) и предложил рассказать о том, что в проекте не так. И почему.
Я довольно четко перечислил причины, по которым считаю, что не достигаем тех показателей, которые были поставлены как цель (вообще-то, это были достаточно расплывчатые критерии оценки, но все же они были).
И (вот тут просто ставлю себе памятник :) ))))) даже четко расписал свои собственные ошибки. Не все, но основные.
После чего мы говорили еще час.
И выяснилось, что этот "вывод продукта на рынок" он рассматривал как "безопасный полигон для отработки ошибок".
Он открывал новый бизнес с новыми партнерами(практически проектную компанию)и не хотел в нем прогореть. В "этом своем" бизнесе он точно знал, что покроет убытки (если таковые случатся). А вот "туда" хотел придти уже подготовленным.
Вопрос. Проект закончился неудачей (производство продукта закрыли, контракты с поставщиками сырья разорвали, перед постоянными клиентами вроде как облажались).
Но был ли проект неуспешным?

Мне кажется, что при выставлении оценки проекту (когда такую оценку выставляет именно внешний "наблюдатель/эксперт") надо быть "менее категоричным". :)

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

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

Если вы PM, то в проекте вам собственно больше и ничего делать не надо, кроме того что оценивать "кто что хочет, кто чего ждет, кто как посмотрит". Так что займитесь делом. :)
"Основную работу" в проекте должны делать другие люди. :)

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

Эволюция орг.структур компаний, методологий ведения проектов (действительно ли "все движется вперед"?)

Недавно посещал некоторые мероприятия и читал некоторые материалы (бывает и такое). Мероприятия и материалы про то, как надо внедрять новое (новые) ...
И по итогам этих материалов/мероприятий как-то задумался. А это вообще эволюция?
Переход от функциональной структуры к проектной, переход от водопада к agile, ... Это точно движение вперед? (выступающие и авторы материалов как-то однозначно уверяют, что именно так и есть).
А меня вот "терзают смутные сомнения".
Мне вот кажется, что эволюция именно в разумном "гибриде" подходов к структурам, методологиям и пр.
Любые крайности - всегда плохо. Так что полностью отвергая какой-то один подход - обязательно что-то теряешь.
В одной из компаний, в которой трудился достаточно долго для того чтобы увидеть (и прочувствовать на себе) процесс построения нового подхода к реализации проектов, как раз сумел убедиться в том, что любое внедрение нового не должно перечеркивать уже существующее.

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

"Поучайте лучше ваших паучат" ("а вот можно без "водички" и сразу к делу?")

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

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

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

Вот так много букв написал чтобы подвести собственно к вопросу - "разделяете ли вы при организаци рабочих совещаний участников вашей команды по уровням вовлеченности?"

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

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

Поэтому и выскажусь (в качестве еще одного "советчика") :) Выскажу "совет" именно как один из вариантов решения.

Если вы чувствуете/знаете, что ваше совещание может вылиться в некое "ни о чем" - берите на себя роль того самого "модератора".
Только без всяких фасилитаций, "давайте будем учитывать каждое мнение и выслушаем всех".
Выслушаем всех. Но только в рамках того, что относится к теме, которую обсуждаем.
Жестко обрывайте тех, кто начинает "разливаться мыслью по древу", вспоминать что было в "его времена", напоминать всем о "новых подходах", предлагать учесть вклад .. И все прочие прибамбасы, не относящиеся к делу.
Не бойтесь именно обрывать. Поучитесь у радиоведущих. У них - каждые 15 минут - новости. А перед определенными "15минутками" еще и реклама. Так что надо вписываться и соответствовать.
Будьте вежливы. Будьте макисмально корректны. Но жестко проводите свою линию - вам нужно получить ответы (согласованные ответы) на вопросы, ради которых вы тут всех собрали.
А истории из жизни, предложения собеседнику "включить голову" или "вспомнить историю" - все это жестко прерывайте. И делайте это сразу, как только заметили, что человек начал "сползать с темы".

Цените свое время. Особенно если вы не любите его проводить на совещаниях.
Лучше тупо и бесцельно поиграть в какую-нибудь очередную компьютерную игрушку  или пересмотреть матч любимой команды за 20.. год, чем сидеть на совещании "очень умных людей".

Вы можете либо в процессе самого совещания (если вы не очень знакомы с участниками), либо (что гораздо эффективнее) до начала совещания определить - кто и какую позицию может занять. Самые "опасные позиции" - "против всех" и "молчун".
Вам нужно как можно быстрее (и точнее) выявить тех участников, которые склонны выполнять на организуемом вами совещании именно эти роли.
(про "молчунов" напишу как-нибудь в другой раз)
Но в процессе проведения собрания/совещания вам необходимо еще более внимательно следить за теми, кто склонен начинать говорить "прописные истины", то что (может быть только по его мнению) "понятно всем и каждому". Именно их и старайтесь вовремя прервать. Пока разговор не перешел в разряд "давайте определимся с терминами".
(если ваше совещание по строго определенным вопросам переходит в обсуждение терминологии - 1. вы неправильно подобрали участников; 2. вы плохо подготовили собрание/совещание)
Если все же такие "потенциально длительные" обсуждения только назревают - пресекайте их жестко.
Ваше совещание/собрание/обсуждение не для того, чтобы выяснить кто умнее (кто больше читал, раньше родился, ..). Вам надо решить абсолютно конкретный перечень вопросов.
Будьте корректны. Но "ставьте на место" любого, кто помешает вам существенно уклоняться от намеченного плана обсуждения.

(планирую по поводу совещаний/обсуждений написать еще немного, но чуть позже, хотя и наболело)

Профессионально курим :)

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

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

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

Не стоит трясти дерево с зелеными плодами.
Придет время - и яблоки сами упадут тебе в руки.

Но ты должен быть готов к этому.
И именно в направлении этой "готовности" ты должен делать шаги.
Остальное все - ерунда.

Все три недели, отпущенные на разработку документа можешь ходить просто плюя в потолок, попивая пиво, танцуя с девченками в клубах.
Если ты не готов сделать документ, то тебе не поможет 40-часовое сидение за столом.
Прими свое "внутреннее дыхание".

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

(Можно было поставить эпиграфом: 
"Лучше день потерять и за час долететь".)

... Ты скажи, ты скажи: Что те надо? Что надо? ...

Этот пост все о той же ситуации: есть Заказчик, есть вы - аналитик, есть запрос "мне нужна вот такая система".

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

Пример из жизни. 

Руководитель отдела продаж оптовой компании обращается с запросом: "нам нужна crm-ка". На вопросы "кто ваши клиенты?", "как происходит общение с клиентами?" он отвечает достаточно подробно и с удовольствием. На вопрос "а кто кроме менеджера по продажам ведет общение с клиентом?" отвечает уже менее бодро. А вопрос "что бы вы хотели получить от CRM-системы?" приводит к пространным объяснениям про полноту информации о клиенте и планировании переговоров с ним (клиентом). И после двух-трех уточняющих вопросов, руководитель отдела "переходит в атаку" - "Лучше расскажите: что она может?"

Про причины такого "не знаю чё хочу, но чувствую, что надо" говорить можно много. Их может быть масса. И сейчас не очень готов писать про каждую из них. 

Хочу привести пару советов - как из такой ситуации выходить? Как добиться от Заказчика описания требований и при этом постараться сделать это в какие-то более-менее приемлемые сроки.

Совет первый. 

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

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

Совет второй.

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

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

Совет третий.

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

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

Совет четвертый.

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

Разные формулировки важны для того, чтобы Заказчик имел возможность сам посмотреть на вопрос с разных сторон. Промежутки во времени - возможность Заказчику подумать. Мнения разных людей важны для полноты картины. 

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

Памятка для заказчика

При выборе разработчика обращайте внимание на:

1.       Есть ли у них «в портфеле» аналогичные разработки»? Наличие близких по функционалу проектов должно не только приятно удивить вас, но и заставить задаться вопросом: не получу ли я шаблонный вариант, который был уже разработан и продан однажды, а теперь просто тиражируется?

2.      Кто предлагается заказчиком в команде проекта?

3.      Как они ведут разработку и какую документацию предоставляют? Методика ведения проектов – один из самых главных критериев при выборе разработчика. Нет правильных ответов – ориентируйтесь на свои предпочтения.

4.      Ну и конечно – рекомендации! Без этого – никуда.

К чему должны быть готовы?

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

2. Основная задача ПМ от разработчика - подписание актов сдачи/приемки и проплата вами счетов. Основная задача аналитика от разработчика - предоставить вам красивый документ (содержание не важно). Основная задача программиста - чтобы вас вообще в природе не было и он вас никогда в жизни не видел.

3.       

Сделайте обязательно:

1. Передайте им свою “хотелку” и дайте разработчику 2 дня на работу с ней. Потребуйте задать вопросы по документу в самом тексте и выслать вам предварительно. Так вы убедитесь, что они ее хотя бы прочитали.
2. Познакомьтесь со всей командой, которая будет работать над вашим проектом. Вы должны знать их всех в лицо. Им тоже будет труднее дурачить вас, если они будут видеть вас лично.
3. Узнайте - зачем в команде которую вам представили так много аналитиков и всего один программист? Почему пришли все стажеры-аналитики и не пришли программисты, которые и будут работать над проектом - они что “такие охренеть важные и занятые”, что не могут оторваться от пива с чипсами для того чтобы посмотреть заказчику в лицо?
4. Представьте разработчику всех, кто от вашего лица может вести переговоры. Обозначьте полномочия в принятии решений для каждого из представленного вами сотрудника.
5. Договоритесь о порядке работы с документами. Их перечень. Версионность. Всегда требуйте чтобы вся команда проекта читала документы. И подписывалась.
6. Разработайте сценарии тестирования. Сделайте это сами.
7. Договоритесь о порядке тестирования. Никогда не соглашайтесь тестировать “финальную версию” без того чтобы протестировать сначала “альфа” и “бета” версии.
8. Еще на этапе утверждения ТЗ начинайте для себя составлять группу пользователей, которые будут тестировать систему. Это должны быть вменяемые сотрудники, выполняющие ключевые функции в бизнес-процессе . Не включайте в группу для тестирования только “операторов” системы.
9. Пропишите срок сопровождения процесса внедрения. Объем вносимых доработок в процессе внедрения. Используйте этот период по максимуму. Все остальные доработки будут “за деньги”.

Пришли с ТЗ к разработчику? Будьте готовы к тому что:

1. К вам будут приходить 10 разных людей от компании (одной и той же, той, где вы решили разместить свой заказ). И будут задавать одни и те же вопросы. Это муторно, но в отличии от рассказов десяти следователям о том как вас ограбили, постоянное пересказывание ваших требований может быть полезно и вам, а не только “следователям”.
2. Ваше ТЗ им совсем не интересно. Они хотят составить свое ТЗ. И это правильно. :)
3. Свое ТЗ они будут составлять за деньги. У них тоже есть аналитики и их надо кормить.
4. Все сроки, которые будут вам озвучены в первые 2 недели общения - вообще не имеют отношения к реальности.
5. Если разработчик “с опытом” - он попытается продать вам “свои готовые решения”. Если он разрабатывает “только для вас” - он впервые делает такой проект.
6. Если не прописали в договоре документацию по системе - ничего не получите. Не получите даже руководств пользователей. Обязательно детально пропишите перечень документации по системе.
7. Если не прописали порядок приемки результата - порядок/сроки тестирования - получите в пользование только бета-версию

2014. Подведение итогов. (мысли, опыт, впечатления)

Удовольствия:

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

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

"Про уродов и людей" (моя версия):

Каким бы уродом ты не был - всегда найдется кто-то, кто будет не против с тобой пообщаться.

Управление проектами:

Проекты бывают не только в IT и строительстве. Но бардак везде один и тот же.
Знания "в области управления проектами" не гарантируют ничего. Отсутствие знаний - не является препятствием. Бери в проект того кто хочет сделать, а не того кто знает как.
Вы можете реализовать 500 страниц важнейших требований, но не сделать значок "закрыть страницу" в виде "большого красивого белого крестика на красном кружочке". И завалите весь проект. Вывод: будь внимателен к деталям.
Люди не говорят о сексе в двух случаях: либо стесняются, либо у них секса так много, что "а чё о нем разговаривать?". Вывод: не додумывай, выявляя требования.

Про общение:

Будь благодарен. Даже когда вроде не за что.
Держись с теми, кто готов учиться. Избегай тех, кто любит поучать (если кто-то рядом произносит "я знаю как надо" - насторожись).

Про всякое:

Когда тебе по-настоящему плохо - тебе никто не поможет. Если кто-то тебе может помочь - значит все еще не так плохо.
Если хочешь многозначительно выглядеть - молчи когда все говорят и иногда многозначительно кивай головой и хмыкай. Но потом не удивляйся что тебя перестанут приглашать на обсуждения. Вывод: будь проще.
"Нет ничего нового в подлунном мире", "ходить по кругу", "каждый раз на одни и те же грабли" - вроде как похожие фразочки. Но только вроде. Вывод: Денис, узри мудрость. Узри ее уже, твою мать.

О разном:

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

За этот год многое узнал. Многое узнал из того, что, может быть, и не следовало узнавать. Но в любом случае - это было полезно.

Вопросы года:
1. Как я до сих пор еще жив несмотря на диагнозы врачей?
2. Зачем девушки часто стоят скрестив ноги?
3. Почему мне часто не хватает "совсем чуть-чуть"?

Имена года:
Юлия и Денис

Оценка года:
Ты зарабатываешь 1000 рублей, а я зарабатываю - 100. Ты успешнее меня?
Но при этом у меня любимая жена и трое замечательных детей. А ты в выходные сидишь один у телевизора и телефон звонит только по работе. Я успешнее тебя? 
Выводы: 1. не сравнивай яблоки и апельсины; 2. не оценивай.

Неудачи года:

Я не смог запустить свою компанию. Не удалось. И дело не в кризисе, не в конкурентности - просто я не смог. Я про..ал. 
Вывод: хорошо, будем пробовать дальше. Будем думать, пробовать. Потому что: а какого хрена, собственно?

Добиться нормальной ремиссии не удалось. Снова говорят о необходмости всякие штуки совершать. 
Вывод: нет никаких выводов.

Я не сумел собраться и начать публично выступать. Просто пока не решился.
Вывод: ну подготовься и выступи уже. Обгадишь все, скорее всего, но зато сделаешь. А там уж будем пилить твои неудачности.

Дауншфтинг мне не удался. Наверное все же я именно такой.
Вывод: пойми - кто ты такой вообще?

Успехи года:

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

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

Ситуацию со здоровьем воспринял спокойно, без нервов, просто с пониманием: "хорошо, будем стараться дальше". (для меня настолько было прорывным было само принятие: "дальше", что заношу это в успехи тоже).

Список успехов пока не полный. Подумаю еще и дополню. 

Впервые выступил в роли "чистого консультанта". Тоже отнесу это к успехам года.

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