23 окт. 2008 г.

Не мешайте мне работать! (Updated)

Всем привет!

cover1 Предлагаю вашему вниманию первый гостевой пост в этом блоге. Речь пойдёт о книге Стаса Давыдова о мотивации под названием «Не мешайте мне работать!» («Motivate me right!»). Книга доступна для скачивания бесплатно в fb2 или pdf-формате. Сам я ещё её не читал, но сделаю это обязательно. А пока предлагаю ознакомиться с отзывом Евгения Охотникова, к мнению которого по вопросам разработки ПО, а также взглядам на управление проектами, я привык прислушиваться. Чего и вам желаю.

Книга неоднозначная. Ценными в ней мне представляются:

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

Ну и написана она довольно живо — легко и быстро читается. Да и небольшая. Сомнения у меня в том, что автор книги является автором озвучиваемых в ней тезисов. Как он сам говорил — опыт работы у него всего 9 лет, по книге выходит, что он отработал в 4-х компаниях. Ряд примеров, которые он приводит в книге напоминают обиды детей на плохих взрослых. Такое впечатление, что опубликованные тезисы он аккумулировал из разных источников (в том числе и из прочитанных им книг), а затем разбавил их примерами из своего не самого большого опыта. Но в целом нет сожаления о том, что прочел книгу. Скорее наоборот — захотелось прочитать парочку книг из тех, которые он рекомендовал.

Диаграмма мотивации (респондент Lamer)

Update:

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

Перво-наперво, спасибо Жене за ссылку на статью «Stop Demotivating Me». У меня даже появилась мысль перевести её на русский язык и опубликовать в блоге. С некоторыми тезисами статьи я также не согласен, но для сведения послушать очередную точку зрения очень полезно.

В продолжение дискуссии в комментах Евгений мне прислал обоснование своей точки зрения о том, что многие моменты в этой книге описаны под влиянием чувства обиды на своего работодателя, и поэтому должны рассматриваться лишь как субъективные заметки к сведению:

Вот, что бросилось в глаза при чтении и запомнилось. Файл motivate-me-right-1.3. pdf размером 4847Kb.

1. Страница 34, «Письмо друга. Александр Беляков».

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

Но ведь человека нанимают для того, чтобы он выполнял ту работу, которая нужна компании. За это ему и платят. Желания разработчика могут учитываться, если они совпадают с нуждами компании. А могут не учитываться, если такового совпадения нет. Что и произошло в данном случае.

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

2. Страницы 60-61.

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

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

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

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

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

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

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

3. Страница 51.

Автор рассказывает о том, как он заделал плохие деревянные рамы монтажной пеной.

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

v-kostin.blogspot.com