Сервис онлайн-образования Яндекс.Практикум запускает курс «Менеджер проектов» для тех, кто хочет управлять созданием и развитием сайтов, сервисов и приложений. Курс прокачивает менеджерские хард и софт-скиллы: чтобы не только делать продукт, но и организовывать процессы и команду так, чтобы все случилось в срок, с нужным качеством и без выгорания.

Выпускники получат диплом о профессиональной переподготовке. Уже доступна бесплатная вводная часть.

Сервис онлайн-образования Яндекс.Практикум запускает курс «Как управлять командой» для действующих руководителей с управленческим стажем менее трёх лет, у которых есть постоянная по составу команда.

Выпускники получат удостоверение о повышении квалификации.

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

Будьте осторожны в своих желаниях — они сбываются!



Так и случилось, что мне предложили нежданно-негаданно руководящую должность, оценившую мои таланты и навыки и позволяющую реализовать свои амбиции. Беседа с менеджером закончилась в лучших традициях “Ты теперь начальник — управляй”. И теперь мне предстояло воплощать в себе лучезарный и кристально-чистый светоч справедливости и делать людей счастливыми, нести слово и байт людям. Однако, почти сразу же оказалось, что это несколько сложнее, чем мне казалось ранее, что угол зрения на проблемы снизу и сверху несколько различается, и родной код оказался приветливее громадины проблем и забот. Поэтому сейчас я решил наконец-то оформить свои догмы на бумаге от лица исполнителя и с призмы начальника. Вряд ли я скажу что-то новое, кроме того, что уже до меня написано в хороших книгах, за исключением примеров из практики и шуток с прибаутками, поэтому либо пролистывайте сразу, либо добро пожаловать под кат.

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

Отчёты — отличная вещь. Они позволяют защищать как заказчика, начальника, так и сотрудника со всем проектом. Они позволяют ими управлять и оценивать их. Вы же, в конце концов пишете код не с усердием дрессированной обезьяны тысячи раз переписывая патерн visitor, а вначале всё-таки сидите и думаете, рисуете на бумажке, планируете код и тесты (я верю в вас!)? Но с другой стороны, отчёты — вещь контроля и организации, которая всех отвлекает от непосредственной работы. И всё равно, в том или ином роде на работе нам приходиться с ними сталкиваться. Зачем и как искать компромисс? Добро пожаловать под кат всем, кому интересно моё мнение по этому вопросу и тем, кто читал мои предыдущие статьи:

От инженера до руководителя. Часть 1: Чувство справедливости
От инженера до руководителя. Часть 2: Делегирование и постановка задачи

Для написания этой заметки  было затрачено:

• 68338 километров на поездки.
• 72 человеко-часа на почтовую переписку.
• 423 человеко-часа на эксперименты с коллективом в 30 человек.
• 88 часов на подготовку докладов и выступления на конференциях.
• 17 чашек кофе на беседу с мудрыми людьми на афтепати.
• Порядка 25 часов на набор этого текста и правку багов в нем :).
• До смерти замученный копирайтер, который был вынужден разбирать мои черновики, аудиозаписи и вообще ему спасибо.

Много денег и времени. Пожалуй, самым затратным (по нервам, времени и деньгам) был эксперимент над собственной командой, о котором мне безумно неловко вспоминать. Но об этом — ниже.

Рано или поздно, наверное, у каждого директора возникает желание платить по справедливости. За выполенную работу. И очень многие сейчас пытаются внедрять KPI (ключевые показатели эффективности). Работает так: вы, как владелец бизнеса, назначаете конкретные цели для сотрудников. Они достигают или не достигают поставленных целей в процессе работы. Тем, кто достиг — выдается плюшка (денежная премия).

Смысл такого подхода: платить по справедливости. На сколько наработал — столько и получил. Это честно, это логично, это — прекрасно!

Ну, логично же, что:

• Продажникам  нужно назначать процент с оборота. Волки должны быть голодными. (Да, есть альтернативное мнение, что применить такой подход — значит «обложить себя дополнительным налогом». Но как по мне — тут все справедливо :-)).
• Офисному планктону — ставить оклад. Стабильность для них — ооочень важное условие существования.

А вот с творческими единицами (дизайнерами, программистами) — все значительно сложнее.

Мы недавно провели опрос руководителей ведущих диджитал-агентств и веб-студий страны на тему «а как вы используете KPI по отношению к труду творческих единиц», в результате получили вот такую картинку:



Некоторые компании (15%) применяют KPI для оценки эффективности труда программистов и дизайнеров.

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

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

… или практическое применение мотивации и краудсорсинга

Привет, Хабр! Ежедневно мы обсуждаем сотни актуальных тем, таких как: GTD, управление проектами, мотивация персонала, работу в команде и другие темы менеджмента. Здесь всегда есть у кого спросить и что прочитать: множество статей, гора учебников, литературы и прочего. В конце концов, мужик: «Ты же получаешь зарплату!». Соответственно, совсем другая тема, ставшая очень актуальной в пору развития ИТ — мотивация людей, которые за свою работу ничего не получают, или, как сейчас модно говорить, краудсорсинг. Об этом и поговорим далее…

Мы встретились с Эдвардом Йордоном во время его недавнего визита в Москву, на конференции Software People. Эдвард — выдающийся разработчик, консультант, писатель («Путь камикадзе», «Смертельный марш. Полное руководство для разработчика программного обеспечения по выживанию в безнадежных проектах», «Закат и падение американского программиста», «Структурные модели в объектно-ориентированном анализе и проектировании») и спикер с более чем 50-летним опытом работы в IT. В июне 1997 года Йордон был принят в члены Зала Компьютерной Славы, наравне с такими грандами IT как Чарльз Бэббидж, Сеймур Крэй, Джеймс Мартин, Грейс Хоппер, Геральд Вайнберг и Билл Гейтс.



Под катом – интервью, которое Йордон дал PayOnline после своего доклада «Особенности и стратегии лучших и худших IT компаний».

 Часто бывает, казалось бы: сплоченный коллектив профессионалов, сильный и качественный продукт на подходе, толстая инвестиционная подушка финансовой безопасности, а что-то не так. Причем, с каждой неделей этих «что-то» становится все больше и больше. Сотрудники нервничают, огромное количество работы проходит в режиме овертайм, постоянные сбои во внутренних коммуникациях, поиск ответственных и виноватых – у победы много отцов, поражение – всегда сирота. Такой деструктивный сценарий развития студии – медленный, но верный путь к завершению её деятельности. Но мы же не просто так собрались несколько месяцев назад?

 Большое количество стартапов «сходят с дистанции» именно из-за того, что в какой-то момент не могут правильно спланировать и проконтролировать своё масштабирование. Любая организация, как живой организм. Отсутствие развития прямо свидетельствует про медленное, но верное умирание. Парадокс заключается в том, что бурный и неконтролируемый рост может привести к обратному от желаемого результату. Через некоторое время компания становится колоссом на глиняных ногах. Ощущение, что все может рухнуть от малейшего дуновения ветерка, изменения конъюнктуры рынка или еще каких-либо глобальных процессов оптимизма совершенно не добавляет. Нервозность, стресс, склоки, падение продуктивности как следствие.

 В этой статье мы попробуем описать наш опыт преодоления подобного рода ситуации. Это было чертовски не просто, но мы с этим справились.

По роду занятий я часто общаюсь с различными русскими и западными командами. Очень частый вопрос — есть ли какая-нибудь специфика в работе наших и как это влияет на разработку?

Есть очень неплохая книжка о специфике работы русских вообще. Она называется «Русская модель управления». Ее написал А.П.Прохоров (другой, не олигарх). Не буду ее пересказывать. Основная идея в том, что русские по своей природе могут работать только в двух модах. В нестабильном состоянии они могут свернуть горы. В это время мотивация очень высокая. В стабильном расслабленном состоянии — когда никто не пинает — русские вроде как работают плохо и не сильно утруждаются.

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

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

Я буду приводить влияние разных факторов в порядке их важности и силы влияния. Чем выше — тем сложнее это изменить и тем больший эффект это оказывает.

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



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

По-моему, эта статья — самое важное, что я в жизни сделал. Не самое сложное, объёмное или интересное, а важное.

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

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

Итак, итоги робосезона 2013:
АвтономныеПодводныеРоботы.Сингапур.Март.2013 = 1 место; // The Singapore AUV Challenge – 2013
ТелеуправляемыеПодводныеРоботы.Сиэтл.Июнь.2013 = 7 место; // 12th Annual MATE International ROV Competition – 2013АвтономныеПодводныеРоботы.Сан-Диего.Июль.2013 = 3 место; // AUVSI Foundation and ONR's 16th International RoboSub Competition – 2013АвтономныеЛетающиеРоботы.Москва.Август.2013 = диплом финалиста :) // КРОК – летающие роботы – 2013

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

Наводим порядок в ИТ-инфраструктуре

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

Читал статью. Статья интересная, однако я думаю что для каждой ситуации есть разные реалии. А так как имею опыт руководства и в сфере разработки и в сфере управления компанией, то я хотел бы прокомментировать некоторые фразы из данного словаря, так сказать пропустив их через призму более обширного мнения, нежели взгляд руководителя по разработке. И дело тут не в том, что разработка ПО вещь специфическая — наоборот, любой руководитель, на мой взгляд должен рассматривать ситуацию со всех граней а потом решать использовать конкретную фразу или нет. Приступим:

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

Но как сделать свою жизнь лучше? Как заставить уровень качества кода расти. Приведу несколько собственных правил-размышлений на эту тему.

Сегодня на глаза попался старый вопрос "Почему работодатель предпочитает нанимать веб-разработчика в офис?": habrahabr.ru/qa/22292. Вопрос был задан еще в 2012 году, но, на мой взгляд, ситуация с тех пор не сильно изменилась.

Коллеги, тут есть серьезное недопонимание, которое давно пора устранить.

Многие, как мне кажется, представляют себе фрилансера примерно так:

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

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

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

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

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

Многие менеджеры, программисты и тестировщики говорят об «эффективности» но не все понимают это слово одинаково. Эффективность это не апельсины или яблоки. Эффективность нельзя положить в пакет, взвесить на весах в магазине и выдать человеку: на, мол, теперь у тебя есть килограмм эффективность. Кушай на здоровье.

Эффективность нематериальна. По этой причине, часто возникают недопонимания даже внутри одного проекта и одной команды.

Целью данного обзора является освещение следующего вопроса: как понимают фразу «проектная эффективность» различные специалисты в сфере ИТ. Мы искренне надеемся, что данное небольшое исследование поможет найти общий язык в понимании термина «эффективность», что и будет первым шагом к достижению высокой эффективности в вашем проекте.

Совсем скоро, 17 декабря, в учебном центре Luxoft Training пройдет мастер-класс Марка Паулка, соавтора модели зрелости возможностей создания ПО (Capability Maturity Model for Software).
Марк Паулк разрабатывает и преподает курсы по разработке ПО, совершенствованию процесса разработки ПО (CMM и CMMI), зрелости процессов, agile-методологиям, управлению проектами по разработке ПО и статистическому анализу.
Предлагаем вам ознакомиться с его статьей, посвященной взаимосвязи между организованностью процесса разработки ПО, качеством ПО и личной производительностью.