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

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

Для успеха каждого проекта критически важно, чтобы все его участники одинаково понимали слова и словосочетания, которые они применяют в общении между собой, и, что даже более важно, понимали разницу между ними. Срок. Продолжительность выполнения задач. Трудоемкость. Трудозатраты. В принципе, ничего сложного и сакрального в этих понятиях нет. Главная сложность состоит в том, чтобы договориться об их единообразном понимании на проекте. Обычно проблемы налаживания таких соглашений вообще не отсвечивают в специальной литературе. Однако в случае, если ваши стейкхолдеры сразу не подтверждают готовность сотрудничать в рамках этих понятий, это главный признак того, что на проекте вы уже имеете проблемы. Большие проблемы. Проявление этих проблем в реальном мире – это только вопрос времени. Ближайшего времени. Это индикатор того, что ваша проектная команда столкнулась с рафинированным менеджером.

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

Поводом для написания этой статьи послужил случай, когда сотрудники нашего HR-отдела предложили мне взять в нашу проектную группу Департамента разработки программного обеспечения ЛАНИТ на производственную практику выпускника одного из московских техникумов.  Кандидат обучался четвертый год по специальности «Прикладная информатика» и, судя по резюме, претендовал на должность «стажера-разработчика SQL, С#, HTML, CSS». Он уже прошел предварительные собеседования и, по словам наших кадровиков, показал себя наиболее адекватным из 15 других претендентов. Поскольку у меня это был не первый случай руководства практикой у студентов и предыдущие прецеденты имели положительный результат, я согласился.

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

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