500 способов грамотно достать разработчика.
(Настольная книга начальника отдела ПО.)
"Товарищ прапорщик, можно я не буду мести плац ломом, а? Давайте я возьму метлу.
Так будет быстрее и лучше..."
"Мне не нужно, чтобы было быстрее и лучше! Мне нужно, чтобы ты задолбался!!!"
Для кого предназначена эта книга.
Данное издание предназначено для руководителей отдела ПО, желающих максимально повысить свой авторитет среди подчиненных и их лояльность по отношению к Компании.
Способ первый - "Босс всегда прав".
Итак, представим ситуацию. У вас грамотный админ SQL, репликация ходит исправно, непрерывно и практически он-лайн. Естесственно, настоящего начальника это не устраивает, ибо ему совершенно ясно, что в данном случае админу попросту нечего делать. Он просиживает в Интернете все время и читает книжки. Что же делать? Спокойствие... Нужно выждать. И вот ваш шанс! Сверху по цепочке вам передали редкое по дальновидности указание... Отправлять все справочники на объекты не он-лайн, а раз в неделю. Каждому админу ясно, что ходившая репликация в режиме 24*7 встанет колом, если ее отправить всю за одну ночь, не говоря уже о воможных разрывах связи... Плюс, каждому разработчику ясно, что без справочников программы не работают. Админ пытается спорить, говорит, что все вернется на круги своя...
Однако, ни в коем случае не принимайте сторону подчиненных! Это дискредитиует вас в глазах начальства. А всем известно, что количество безмолвных кивков головой на любые указания прямо пропорционально времени нахождения на должности и в фаворе.
Итак, распоряжение админу - снести всю репликацию... Не беда, что нужно делать ночью, подумаешь, всего-то пару ночей посидеть...
Все сделано, ура! Но что это? На склад не могут оприходовать товар? Вот черт, забыли, что справочники-то в офисе вводят. Кошмар! Черт, ладно - просто "пихнем" их на первый раз и заставим админа посидеть еще ночку, чтобы вернуть назад репликацию на склады. Фу, отдышались... Опять проблемы? Магазин не может принять товар? Он завис в транзите??? Не беда, еще ночь, проведенная админом за компом - и все вернется на круги своя... Видите, как здорово получилось? И с начальством не спорили и админ при деле....
Эффективность метода - 50%. Не знаю, насколько админы терпеливы...
Способ второй - "Срочность"
Способ второй, чуть более эффективный... Выберите наиболее занятого разработчика, который по совместительству еще и сотрудник технической техподдержки. Желательно уникального по исполняемым обязанностям в отделе. Вам приходит расплывчатый указ с пометкой "срочно". Не понятен ни заказчик, ни, что, собственно, делать... На робкие попытки сотрудника, действовать согласно Регламенту - указать ключевых пользователей, предоставить описание задачи - строго потребовать немедленных действий. Желательно регулярно отрывать человека от работы вопросами типа "Ну, как?" или "Это нужно еще вчера", чтобы постоянно держать его в напряжении и на нервах.
Наконец, он справился. Молодец, однако вопрос остался открытым - для кого, собственно, он это делал и как все это проверить, и сдать в эксплуатацию... Ни в коем случае не отвечайте на этот вопрос ни сегодня, ни завтра, пусть разработчик помучается пару-тройку дней сознанием того, что где-то все летит в тар-тарары, а он ничего не может поделать...
Эффективность метода - 70%. Не дай Бог, вам достанется пофигист, которому все до лампочки... Проходит только с работниками с развитым чувством ответственности.
Способ третий - "Доверие".
Ну а этот способ является одим из самых изящных... Эффективность - 80%. Но больше подходит к новичкам в отделе. Так можно, во-первых сразу сбить с них спесь, а во-вторых сразу показать, кто в доме хозяин.
Выберите самый сложный и ответственный проект Компании. А еще лучше два или три. И просто скиньте на него все что получится, пока он не завоет. А так как человек он новый, да еще, если повезет, на испытательном сроке - то сразу выть он не будет... Сначала попытается тянутся, пахать по 12 часов в день, в выходные, дабы не уронить честь программиста....
Следите за ним. Ни в коем случае не давайте ему старшего, который может подсказать, помочь, проделать Review Code и тем самым смягчить те последствия, которые могут произойти...
Обязательно поддерживайте все (!) акции вышестоящего начальства направленные на изменения в поддерживаемых этим человеком программах и попутно сваливайте на него еще по паре проектов в неделю...
И самое главное, поскольку в случае проблем вы косвенно несете ответственность за своего человека, в следующей главе мы расскажем о том, как этой ответственности грамотно избежать.
