10 правил как работать меньше, а успевать больше (на самом деле нет)

Я давно хотел написать о книгах, которые читаю, и околокнижных сервисах, которыми пользуюсь.
Один из таких сервисов – это smartreading.ru. Сервис представляет собой рефераты книг, т.е. главные идеи, описанные в книге, без авторской воды. У меня там даже есть платная подписка.
Насколько помню – автор сервиса Михаил Иванов, тот который Манн, Иванов, Фербер.
Он давно уехал из России и уже на постоянной основе живёт в США, что уже говорит о том, что он умный человек.

Также я конечно читаю их фейсбук и блог. Сегодня вот опубликовали 10 правил как работать меньше, а успевать больше. Сначала хотел написать им комментарий, а потом решил, что это потянет на статью в моём блоге, плюс я сам не потеряю эту информацию.

Я конечно понима, что “кто я, а кто Джефф Сазерленд” и “куда ты лезешь со своим убогим мнением”, но…

1. Одно совещание в день. Это прекрасное начало, вот только непонятно для кого написано. Если у менеджера несколько проектов – у него по-умолчанию несколько совещаний. Если это обычный разработчик – то ему не надо ежедневное совещание. Вот не надо. У меня у самого двадцатилетний опыт работы в IT. Вполне хватает еженедельных совещаний, а зачастую даже один раз в две недели собрались – решили что делать и арбайтен!
Кстати, чтобы совещание проходило за 15 минут каждый человек, учавствующий в нём, должен потратить никак не меньше часа на выяснение повестки, согласования всяких сопутствующих вопросов и т.д. Так что это очень удобный миф, насчёт пятнадцатиминутных совещаний.

2. Работа должна быть видимой. Ну т.к. автор всех этих советов является автором скрама, то оно и понятно, что он будет пропагандировать свою систему. Но, зачастую, трёх скрамовских колонок недостаточно. А причина в том, что некоторые задачи решаются по водопадной модели, которая вообще не вписывается в скрам. И обычные разработчики не дадут соврать – таких задач всегда очень много в любом проекте.

3. Команды должны быть маленькими. Команды не должны быть маленьмим иои большими – команды должны решать поставленные задачи. Если для реализации проекта в команде должно быть 20 человек, то их там ровно столько и должно быть.

4. Не нужно повестки дня — обозначайте конкретные результаты. Самый бредовый пункт. Ещё бредовее выглядит его описание у автора. Причём и сам пункт и описание никак не согласуются с первым пунктом о мифическом пятнадцатиминутном совещании. Без повестки совещание будет длится не час, и не два. Подготовку к совещанию конечно никто во временные рамки не включает – очень удобно и очень хитро! Напоминает мне старую рекламу: “Три CD-ROM по цене четырёх. Четвёртый диск БЕСПЛАТНО!!!”.

5. Забудьте о должностях, порвите визитки. Эм…. если вы будете опираться только на членов, прости господи, команды, то у вас дизайнера “попросят” кодить бекэнд сервиса. Ну а если брать иерархию сеньор-мидл-джуниор – то тут вообще никто и никогда её забывать не будет по одной простой причине – в зависимости от “должности” человек может решать задачи определённой сложности и важности.

6. Никаких прерываний. Первый, и как оказалось единственный, пункт, к которому не придерёшься.

7. Только один проект за раз. К сожалению реальность такова, что грамотные специалисты в меньшинстве и их ресурсами надо пользоваться с умом. Сеньор не должен сидеть и ждать пока джуны с мидлами поделают свои части задач, поэтому его знания разумно использовать в других проектах.

8. Ставьте приоритеты. Читаем авторское описание. Гы-гы-гыкаем. А как же 7-й пункт-то!?

9. Не надо героизма. Ага-га, а слова “дедлайн” нету, и его выдумали, чтобы пугать неопытных джуниоров. Открою секрет – весь современный интернет построен на “героизме”. Иногда из под палки, но довольно часто и на энтузиазменном “героизме”.

10. Сожгите табель учета рабочего времени. Прекрасно, просто прекрасно. Один только вопрос – как этот достойный господин собирается выставлять счёт закачику? Конечно в соременном мире дико требовать от разработчика сидеть с 9 до 18. Но то, что при составлении плана разработки во главу угла ставится время – думаю этого никто отрицать не будет. Первый вопрос у менеджера к разработчику – за сколько ты это сделаешь, да?

Вот такой вот мой “комментарий” на статью.
Добавляйте свои, если тут есть кто живой – может даже срачик устроим 🙂

Оставить комментарий

Your email address will not be published. Required fields are marked *