Записки автоматизатора. Профессиональная исповедь

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

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

2. Сотрудник, который знает свое непосредственное дело хуже вас, – плохой сотрудник. Я исхожу из предположения, что вы собрались делать дело, а не тешить свое самолюбие.

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

4. Качество и производительность труда программиста всегда можно понизить с помощью отрицательного материального стимулирования. Например, понижая ему зарплату после каждого внедрения, можно добиться полного отсутствия уже третьего внедрения.

5. Очень просто людей, преданных вам, превратить в людей, преданных вами. Чьи-либо успехи в обратных действиях мне неизвестны.

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

Буратино в отделе

(Конспект лекции, прочитанный одному Буратино из отдела ИТ летом 2003 года)

Как ни печально, на работе люди используются утилитарно. Единственная задача, которую я выполняю в роли начальника, это техническое обслуживание, наладка и ремонт механизма под названием «отдел» для того, чтобы он мог выполнять свои функции. Люди при этом соответствуют деталькам, совместная работа которых как раз и приводит к тому, что механизм работает. Если с одной из деталек происходят какие-то изменения, я ее должен осмотреть, отремонтировать или изъять, после чего переналадить механизм так, чтобы он мог продолжить свою работу.

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

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

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

Формулирование задач

В соответствии с российскими (и, кстати, американскими) стандартами составление технического задания (ТЗ) возлагается на разработчика. Это естественно, так как обычно клиент сам не знает, чего хочет, что можно реализовать и как.