JonnyX

набережная реки Фонтанки, 24

Окна гимназия №190 выходят на эту стену

Способ первый - "Босс всегда прав".

Итак, представим ситуацию. У вас грамотный админ SQL, репликация ходит исправно, непрерывно и практически он-лайн. Естесственно, настоящего начальника это не устраивает, ибо ему совершенно ясно, что в данном случае админу попросту нечего делать. Он просиживает в Интернете все время и читает книжки. Что же делать? Спокойствие... Нужно выждать. И вот ваш шанс! Сверху по цепочке вам передали редкое по дальновидности указание... Отправлять все справочники на объекты не он-лайн, а раз в неделю. Каждому админу ясно, что ходившая репликация в режиме 24*7 встанет колом, если ее отправить всю за одну ночь, не говоря уже о воможных разрывах связи... Плюс, каждому разработчику ясно, что без справочников программы не работают. Админ пытается спорить, говорит, что все вернется на круги своя...

Однако, ни в коем случае не принимайте сторону подчиненных! Это дискредитиует вас в глазах начальства. А всем известно, что количество безмолвных кивков головой на любые указания прямо пропорционально времени нахождения на должности и в фаворе.

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

Все сделано, ура! Но что это? На склад не могут оприходовать товар? Вот черт, забыли, что справочники-то в офисе вводят. Кошмар! Черт, ладно - просто "пихнем" их на первый раз и заставим админа посидеть еще ночку, чтобы вернуть назад репликацию на склады. Фу, отдышались... Опять проблемы? Магазин не может принять товар? Он завис в транзите??? Не беда, еще ночь, проведенная админом за компом - и все вернется на круги своя... Видите, как здорово получилось? И с начальством не спорили и админ при деле....

Эффективность метода - 50%. Не знаю, насколько админы терпеливы...

Способ второй - "Срочность"

Способ второй, чуть более эффективный... Выберите наиболее занятого разработчика, который по совместительству еще и сотрудник технической техподдержки. Желательно уникального по исполняемым обязанностям в отделе. Вам приходит расплывчатый указ с пометкой "срочно". Не понятен ни заказчик, ни, что, собственно, делать... На робкие попытки сотрудника, действовать согласно Регламенту - указать ключевых пользователей, предоставить описание задачи - строго потребовать немедленных действий. Желательно регулярно отрывать человека от работы вопросами типа "Ну, как?" или "Это нужно еще вчера", чтобы постоянно держать его в напряжении и на нервах.

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

Эффективность метода - 70%. Не дай Бог, вам достанется пофигист, которому все до лампочки... Проходит только с работниками с развитым чувством ответственности.

Способ третий - "Доверие".

Ну а этот способ является одим из самых изящных... Эффективность - 80%. Но больше подходит к новичкам в отделе. Так можно, во-первых сразу сбить с них спесь, а во-вторых сразу показать, кто в доме хозяин.

Выберите самый сложный и ответственный проект Компании. А еще лучше два или три. И просто скиньте на него все что получится, пока он не завоет. А так как человек он новый, да еще, если повезет, на испытательном сроке - то сразу выть он не будет... Сначала попытается тянутся, пахать по 12 часов в день, в выходные, дабы не уронить честь программиста....

Следите за ним. Ни в коем случае не давайте ему старшего, который может подсказать, помочь, проделать Review Code и тем самым смягчить те последствия, которые могут произойти...

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

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

Способ четвертый - "Удар в спину"

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

У вас еще нет справочников которые напрямую интегрированы с 1С, где полновластным хозяином являются финансисты, и могут сделать с ними все, что им заблагорассудится? Обязательно распорядитесь завести их... Что, уже есть? Прекрасно, тогда ждите, придет ваш час.

И он настал! Сказать, что финансисты поставили справочник с ног на голову и вывернули наизнанку - значит ничего сказать. Поменяли все, что только можно, в том числе идентификаторы. Для непосвященных объясню, это значит, что магазин стал складом, а склад вообще исчез :-). Разобраться в этом бардаке ни одну программисту сходу не удастся... Он, конечно, сначала начнет возмущатся, но потом поймет, что, делать нечего, надо спасать ситуацию и побежит к вам за помощью. Вот тут-то вы и примените все свои знания полученные из этого издания!

Он просит 10 дней на спасение ситуации? Его достают пользователи? И сам он переживает за свою программу? Пустяки - одно-единственное ваше обличающее письмо с мягкими укорами вашему разработчику ("Программы нужно писать так, чтобы их не клинило при изменении справочников") с копией ключевому пользователю программы и начальнику параллельного отдела по совместительству - сразу расставит все по своим местам! Не забудьте щедро сдобрить его хвалебными лозунгами в адрес руководства. Виновные выявлены! Меры приняты!

Гарантирую - популярность и успех обеспечен. Ваше письмо распечатают и повестят на стену, как лозунг на все времена!

Эффективность - 100%.

Источник http://reactor.cc/post/662076

Забота по-новосибирски