Как пасти котов. Наставление для программистов, руководящих другими программистами. Дж. Ханк Рейнвотер

работы.

      Так пусть ваши программисты работают дома – это один из лучших способов исключить раздражающие факторы и поднять продуктивность. Но и здесь не все так просто! Некоторым сотрудникам такой режим работы подходит лучше всего; другим полезно появляться на работе хотя бы раз в неделю; в любом случае, эффективной деятельности в режиме «на дому» достигают только самые дисциплинированные. Выбрав этот путь, вы будете вынуждены уделять довольно много времени проверкам. Опытным и надежным сотрудникам можно доверить работу на дому; что касается остальных – дайте им возможность попробовать, но обязательно проверяйте новые показатели продуктивности. Если отделения компании, в которой вы работаете, рассредоточены по всему земному шару, и у вас фактически нет выбора, будьте готовы к тому, что с прижатой к уху телефонной трубкой придется проводить по 10 часов в неделю, а от электронных сообщений не будет отбою. Схема работы на дому очень перспективна, но чтобы заставить ее приносить плоды, вы должны учесть все тонкости.

      Когда проект разрастается

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

      Рассмотрим типичный процесс производства программного продукта. Вне зависимости от того, что вы предпочитаете – стремительный напор или постепенные итерации, – процесс этот всегда состоит из нескольких фиксированных этапов.

      1. Замысел. У кого-то появляется блестящая идея.

      2. Специфицирование. Куча людей пытаются описать эту идею.

      3. Проектирование. Высокоинтеллектуальные товарищи решают, как сконструировать предполагаемый программный продукт.

      4. Конструирование. Бессонными ночами и нескончаемыми днями программисты программируют.

      5. Тестирование. Обнаруживается, что конечная реализация блестящей идеи не так хороша, как хотелось бы, или, еще хуже, что идея-то отнюдь не блестящая.

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

      А теперь подумайте: таким ли уж неожиданным станет разрастание рамок в контексте отраженного в этом списке реального сценария? Мне так не кажется, и вам тоже не должно так казаться. И тем не менее, если речь об этом зайдет, воя и зубовного скрежета программистов не избежать. Как заставить их поверить, что вы во всеоружии и ваша позиция правильна? Лучше всего поставить