Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте - Йордон Эдвард Страница 26

Тут можно читать бесплатно Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте - Йордон Эдвард. Жанр: Компьютеры и Интернет / Программирование. Так же Вы можете читать полную версию (весь текст) онлайн без регистрации и SMS на сайте «WorldBooks (МирКниг)» или прочесть краткое содержание, предисловие (аннотацию), описание и ознакомиться с отзывами (комментариями) о произведении.
Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте - Йордон Эдвард

Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте - Йордон Эдвард краткое содержание

Прочтите описание перед тем, как прочитать онлайн книгу «Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте - Йордон Эдвард» бесплатно полную версию:

Книга Эдварда Йордона «Путь камикадзе» представляет собой полное руководство по выживанию в безнадёжных проектах, предназначенное для разработчиков программного обеспечения. Практически каждому разработчику ПО и менеджеру приходится сталкиваться с проектами, характеризующимися никуда не годными персоналом, планом и бюджетом, т.е. проектами, обречёнными на неудачу. В условиях реинжиниринга корпораций безнадёжные проекты становятся «стилем жизни» многих организаций. Книга Эдварда Йордона является руководством по решению следующих проблем: выживание в проектах, обречённых на неудачу; достижение оптимальных соглашений во время переговоров; управление персоналом и расстановка приоритетов; выбор средств и технологий; определение момента, когда уже пора выйти изпроекта. Эдвард Йордон применяет свою уникальную технологию и интуицию менеджера к наихудшим вариантам софтверных проектов, показывая, как максимально повысить шансы на успех, или, по крайней мере, вывести вашу карьеру из-под удара. Шаг за шагом Йордон проходит все стадии жизненного цикла проекта, учит менеджеров и разработчиков правильно вести себя с заказчиками и оптимально использовать доступные ресурсы, включая людей, средства, процессы и технологию. Учитесь проявлять необходимую гибкость при проведении переговоров, расставлять осмысленные приоритеты и… вовремя выходить из проекта. Если вам когда-либо требовалось совершить невозможное, «Путь камикадзе» – ваша книга.

Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте - Йордон Эдвард читать онлайн бесплатно

Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте - Йордон Эдвард - читать книгу онлайн бесплатно, автор Йордон Эдвард

Допуская возможность такого вознаграждения, сделаем некоторые замечания:

5) Не забывайте о том, что 20%-ное повышение зарплаты имеет гораздо большее значение для молодого программиста, зарабатывающего 25,000$ в год, чем для опытного и квалифицированного программиста, зарабатывающего 75,000$ в год. При более высокой зарплате предельная налоговая ставка обычно существенно выше и может достигать 50%, поэтому опытный программист приносит домой не намного больше молодого, и, следовательно, зарплата при этом рассматривается, скорее, как фактор гигиены. Что же касается молодого программиста, налоговая ставка при его зарплате достаточно низка, и этих 20% может вполне хватить для выплаты ежемесячных взносов за его первый автомобиль или переезда от родителей в арендованную квартиру.

6) Помните, что возможность заработать большие деньги может по-разному подействовать на мотивацию людей. Руководство может полагать, что она просто побудит всех работать более интенсивно, однако, она может также заставить участников команды чересчур критически и подозрительно относиться друг к другу – например, какой-либо из участников команды может выразить своё недовольство следующим образом: «Джордж имел наглость отсутствовать в сочельник на работе, чтобы побыть со своей глупой семейкой, как раз тогда, когда у нас был важный этап тестирования. Похоже, он собирается оставить нас без премии!»

7) Помните, что размер премии отнюдь не связан прямой, линейной зависимостью с продуктивностью или количеством времени, затрачиваемого проектной командой. Мне приходилось наблюдать, как в некоторых организациях высшее руководство пытается соблазнить проектную команду двойной премией – обычно при отставании проекта от графика – поскольку руководство, очевидно, верит, что двойная премия заставит людей работать вдвое больше. Однако, если участники команды уже работают по 18 часов в день, законы физики не позволят работать вдвое больше даже самым рьяным из них.

8) Для того, чтобы премия работала как стимул, проектная команда должна верить, что она реально существует и высшее руководство не будет искать удобный предлог, чтобы отменить её. Разумеется, если вознаграждение связано с успехом на рынке, то никаких гарантий быть не может – например, даже если проект закончится успешно, то возможный обвал на финансовом рынке может нарушить все планы компании по продвижению её продукта. Однако, если премия целиком зависит от высшего руководства, и проектная команда знает, что в предыдущих безнадёжных проектах их участники самым бессовестным образом были оставлены без всякого вознаграждения, то «обещание» премии сыграет, скорее всего, роль отрицательного стимула. Аналогично, если проектная команда приходит к выводу, что она практически не влияет на успех проекта – например, он может зависеть от своевременной поставки нового оборудования, которое разрабатывается внешним поставщиком – то обещанная руководством премия будет восприниматься скорее как «игра в лотерею», а не как стимул.

9) Проектная команда должна также верить, что распределение премии будет справедливым. Это вовсе не означает уравниловки; однако, если команда знает, что львиная доля вознаграждения достанется менеджеру проекта, а другим участникам останутся крошки со стола, то результат предсказуем. Такие вопросы необходимо обсуждать в самом начале проекта; вряд ли участников проекта могут успокоить такие заявления менеджера, как «доверьтесь мне и ни о чем не беспокойтесь – я приложу все усилия, чтобы каждому досталось по справедливости».

Что касается проектов, в которых большие премии невозможны или нежелательны, менеджеру проекта важно не забывать о том, что существуют достаточно разнообразные виды нематериального вознаграждения, с помощью которых можно так же серьёзно стимулировать участников проекта. Это также справедливо и для «нормальных» проектов, но для безнадёжных особенно важно. Важно также помнить, что пресс, под которым находится команда безнадёжного проекта, давит также и на членов их семей. Как отмечает Doug Scott:

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

Букет цветов – это, конечно, красивый жест, но для членов семьи иногда важнее более «практичные» вознаграждения – особенно для супруги, которая вынуждена в одиночку управляться с хозяйством и ухаживать за детьми, в то время как её «сильная половина» пропадает круглые сутки в безнадёжном проекте. Внимательный менеджер проекта может выяснить, нужно ли супруге такси, чтобы отвезти ребёнка домой из школы, или может ли кто-нибудь в офисе по дороге домой заглянуть в магазин, чтобы помочь супруге, которая сидит дома с больными детьми. Если дети действительно серьёзно больны и нуждаются в медицинской помощи, то менеджер проекта должен перевернуть землю, если потребуется сломать бюрократические преграды, и сделать все, чтобы обеспечить необходимую помощь и успокоить участника проекта, волнующегося о своей семье.

Конечно, такая забота требует денег, но, как правило, не таких уж больших, которые вполне укладываются в статью бюджета под названием «прочие затраты». Конечно, если бюрократы обнаружат это, то они поднимут вой, что такие расходы официально не предусмотрены. Менеджер, который уступит такому нажиму, будет просто бесхарактерной тряпкой; если это необходимо, менеджер должен оплачивать такие расходы из своего собственного кармана, поскольку он обычно получает гораздо большую зарплату, чем технические специалисты в его команде. В любом случае, воевать с бюрократами – это забота менеджера; самое последнее дело вынуждать технических специалистов попусту тратить своё время и эмоциональную энергию на борьбу с бухгалтерией, чтобы доказать им целесообразность покупки дополнительной пиццы на ужин, если команда задержалась на работе до позднего вечера.

Скромные вознаграждения такого рода в течение всего проекта обязательно сделают своё дело, однако существуют и более действенные нематериальные поощрения, которые могут быть сделаны по окончании проекта. Я не имею ввиду продвижение по службе или новые возможности для карьеры, которые в конечном счёте попадают в ту же категорию, что и прямые денежные вознаграждения. Ниже приведены примеры некоторых поощрений, которые, может быть, не так действенны, как премиальный чек на миллион долларов, но, тем не менее, могут оказать благотворное действие в безнадёжном проекте:

10) Дополнительный отпуск – если проект закончится успешно, предоставьте его участникам отпуск такой же продолжительности, как и весь проект. Большинство из нас не знает толком, что делать с двухнедельным отпуском – однако, если бы нам предоставили шестимесячный оплачиваемый отпуск, мы могли бы отправиться в кругосветное морское путешествие, о котором всегда мечтали. Любопытный тест: выскажите эту идею своему менеджеру и посмотрите на его реакцию. Если вы услышите что-нибудь наподобие: «Что?!? Ты, наверное, спятил? Шестимесячный отпуск за шестимесячный проект?!? Мы дадим тебе пару дней и не вздумай больше искушать судьбу!», то это означает только одно: менеджер полагает, что разработчики ПО – это не более чем бессловесные рабы. Такая позиция многое говорит о том, какое отношение к трудовым соглашениям принято в данной организации.

11) Оплаченная свобода действий – когда безнадёжный проект завершится, привлеките участников команды к шестимесячной работе над «Проектом Х» (эту замечательную идею предложил Larry Constantine на конференции по программному обеспечению в Мельбурне в 1995 году). Вопрос: что такое «Х»? Ответ: все, что они пожелают. Вместо того, чтобы сразу же оказаться втянутыми ещё в один безнадёжный проект (или в скучный до безобразия «нормальный» проект, что на самом деле ничуть не лучше), участники команды получат хорошую возможность в течение шести месяцев осваивать Java, изучать новейшие объектно-ориентированные методологии или даже вернуться в колледж, чтобы получить свою степень магистра. Надо проявить некоторую изобретательность, придумывая «официальное» название для Проекта Х, чтобы поставить в тупик бюрократов; что-нибудь вроде «эвристической объектно-ориентированной клиент-серверной системы стратегического прогнозирования с возможностями Internet» может произвести необходимый эффект.

Перейти на страницу:
Вы автор?
Жалоба
Все книги на сайте размещаются его пользователями. Приносим свои глубочайшие извинения, если Ваша книга была опубликована без Вашего на то согласия.
Напишите нам, и мы в срочном порядке примем меры.
Комментарии / Отзывы
    Ничего не найдено.