20

Как работать с программистом-перфекционистом

Серия Франчайзи на грани нервного срыва
Как работать с программистом-перфекционистом

– Альберт, ты сделал справочник для расчета накладных расходов?

– Я даже не начинал.

– Слушай, нам эта доработка уже неделю, как нужна. В чем проблема?

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

– А что ты предлагаешь?

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

–  И сколько времени займет эта разработка?

– Думаю, дня за три сделаю.

– Да, Альберт, это классное решение. Проблема только в том, что заказчик согласовал нам всего 40 часов на новый документ «Плановая себестоимости изделия». Из них на справочник «Формулы для расчета расходов» выделено 4 часа. Давай попробуем обойтись без конструктора формул.

– Это невозможно! Ваше решение с редактируемыми формулами в строке – нерабочее!

– Ну, слабое место ты увидел правильно… Вот что мы сделаем. Над строкой для ввода формулы мы напишем текстом, какие переменные и выражения с ними можно использовать. А еще ты запрограммируешь простую проверку введенной формулы. До того, как программа начнет вычислять реальные накладные расходы по ней. Пользователь сможет поправить ее вручную после сообщения об ошибке. Сколько времени займет такая разработка?

– Пару часов. Но я не уверен, что это хорошее решение.

– Я уверен. Я отвечаю за этот проект. Сделаем так, как я говорю.

– Смотрите сами. Я сделаю, конечно, то, что вы просите. Но я вас предупредил.

К вечеру справочник был готов. Без конструктора. С подсказкой и проверкой введенной формулы. Не очень удобный, не очень красивый. Но вполне работоспособный.

Вот такой у меня был сотрудник. Перфекционист. Он предъявлял очень высокие требования к результатам своей работы. Стремился к совершенству. У него получался прекрасный код. Возможно, самый лучший в компании. Заказчики его тоже очень любили. Он видел все слабые стороны обсуждаемых решений. И предлагал лучшие варианты. Но в стремлении к совершенству Альберт не учитывал реальные требования и возможности заказчиков. И часто откладывал начало работы. Не только потому, что долго продумывал совершенное решение. Но и потому, что у него рука не поднималась делать то, за что заказчики готовы были заплатить. Денег на совершенство никогда не хватало.

...

– Рустэм, снимите меня с проекта.

– Альберт, да ты что?! Как я тебя сниму, ты – руководитель этого проекта!

– Я не справляюсь. Гузель – негодный консультант. Я вчера посмотрел, что она пишет в инструкциях пользователям, и ужаснулся. Мы завалим этот проект, точно. Я опозорюсь!

– Ты говорил с ней?

– Говорил. Но это бесполезно. Если человек не умеет писать инструкции, за два дня ее не научить. Она не чувствует, в чем может быть проблема пользователя. Не описывает все возможные ситуации.

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

– Техподдержка будет сходить с ума. Они перегрузят ее звонками. Но это еще ладно. Хуже то, что многие в техподдержку просто не позвонят. Плохо обученные, они введут неверные данные! В итоге мы не закроем опытную эксплуатацию в срок! Я очень не хочу во все это вляпаться.

– Но у меня нет ни одного свободного руководителя проекта. Я просто не могу тебя заменить!

– Вам придется. Если вы не хотите катастрофы.

– Ладно. Я не могу заменить тебя. Но я могу заменить твоего консультанта. Евгения как раз освободилась. А Гузель переведем на проект попроще.

Мы заменили консультанта и после пары-другой истерик Альберта проект был все же завершен. Но каких нервов мне это стоило!

...

– Альберт, поздравляю.

– С чем?

– С успешным завершением проекта. Акт подписан. И отзыв получен. Тебе полагается премия.

– Премия? За что? Да заказчик просто не понимает, как там все плохо.

– В смысле – плохо?

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

– Погоди. Постановка налогового учета не входила в рамки проекта. Как-то же она его ведет? Нам не жалуется. Пользователей мы обучили. Я лично подписал сертификаты на допуск к программе двум десяткам специалистов. Конечно, они будут косячить, это неизбежно. Но техподдержка в отделе ИТ организована. Они точно справятся.

– Нет, все плохо. Я не могу получить премию за такую работу.

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

Попробуем понять, что же «не так» с перфекционистом и как с ним работать.

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

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

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

5
Автор поста оценил этот комментарий

По первому примеру не очень поняла. Есть сроки по этапам проекта и трудозатраты на разрабатываемые модули. Заказчик согласует те объемы, на которые у него есть время и деньги. Так почему программисту не ставят задачу сделать решение в рамках ограничений? Обычно опытные специалисты сразу смекают. Требуется не идеальное решение, а то, которое лично ты сможешь реализовать за отведенное время. Эта разработка и будет считаться оптимальной в рамках контекста.

Исходя из общения с программистами, которые стали РП, поняла, что им важно иметь возможность набирать команду под себя. Соответственно, часть проблем можно решить таким путём (непростой, но рабочий).

А вообще таким людям в РП делать нечего. Они прекрасные эксперты и должны заниматься тем, что лучше всего умеют. Почему его сделали РП?

раскрыть ветку (1)
1
Автор поста оценил этот комментарий
В итоге он ушел из РП и снова стал программистом. И прекрасным экспертом по оптимизации производительности больших систем. Но пробовали мы с ним все, включая начальника отдела.
показать ответы
2
Автор поста оценил этот комментарий
Сейчас увидел, что ТС это ГД. Тем не менее, я с вами не согласен. Моральный дух в IT после таких решений стремится к нулю. Прошу прощения, если где обидел
раскрыть ветку (1)
1
Автор поста оценил этот комментарий
У вас нормальное мнение, и корректно (для Пикабу) выраженное. Спасибо за ваш отклик
2
Автор поста оценил этот комментарий
«Заказчик доволен» это хорошо. Но не случилась ли у вас ситуация после выполнения этого кейса, когда в вас стали долбить с просьбами помочь/обновить/перезалить или «вовсе все упало, почините»?
Я в своем длинном ответе делал упор на мысль: «сделай правильно и сразу, найдя компромисс». Компромисс находится по матрице рисков. Малейшая ошибка в проектировании дает несравнимо большие проблемы, нежели +5 мин на проектирование и разработку.
Для примера: сегодня вы хотите взять ипотеку 1млн с зп 50к и отказываетесь. А завтра у вас пусть и 100к зп, но квартира уже 20млн.
Может пример и глупый, но зато приземленный.
И да, если вы аутстафф, а не делаете ради себя, то это рабочая бизнес-модель подписки 😅
Но тогда это уже «замысел», а не «перфекционизм».
раскрыть ветку (1)
0
Автор поста оценил этот комментарий
Полностью согласен, что лучше более тщательно все спроектировать, чем переделывать все при эксплуатации. Но в этом случае ошибок в проектировании не было, это просто разные подходы. Если заказчик платит за жигули, делать ему мерседес за свой счет - неверно. Ведь и техподдержка на мерседес - дороже. Не стоит в проекте с ограничением по бюджету увлекаться хотелками даже не заказчика, а программиста
0
Автор поста оценил этот комментарий
Как я и писал - проект сдан - ну и хуй с ним!
раскрыть ветку (1)
0
Автор поста оценил этот комментарий
Зря вы так - всегда нужно думать о долгосрочных отношениях с заказчиком
показать ответы
0
Автор поста оценил этот комментарий
Я имею в виду: "Проект сдан, деньги получены, премии выписаны, и хуй ним." А все проблемы - это проблемы пользователей и техподдержки.
раскрыть ветку (1)
0
Автор поста оценил этот комментарий
Не знаю, конечно, что вы там додумали себе, но систему нормально сопровождал ИТ отдел завода. А нас пригласили еще на два проекта. Но у вас прям боль какая-то. Подрядчики обижали? Поделитесь
показать ответы
1
Автор поста оценил этот комментарий

Так в вашем примере он оставляет всё как есть и ни слова не говорит о возможных проблемах.

раскрыть ветку (1)
0
Автор поста оценил этот комментарий
Наверное, вы не поняли. В первом примере - Если программа запрещает вводить некорректные данные и дает комментарий - это нормальная работа программы. Или вы другой пример имеете в виду?
показать ответы
2
Автор поста оценил этот комментарий
Интересно, а руководитель также относился бы к ПО, если бы от него зависела жизнь?
Например, прошивка аппарата ИВЛ? Система СКД в торговом центре, которая при пожаре запрёт наглухо все двери, когда его семья пойдёт туда за покупками?
А если бы другие также относились к своей работе? Отдал руководитель машину на сход-развал, мастер заметил утечку тормозухи и не сказал - потому что заказчик не просил проверить ее уровень. На с
на следующий день поехал с семьёй в отпуск и все, кроме него умерли.
раскрыть ветку (1)
0
Автор поста оценил этот комментарий

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

показать ответы
0
Автор поста оценил этот комментарий
Нормальный веб-сервис да еще и с конструктором «за 3 дня» это просто сказка, если у Вас есть такой опытный фулл-стэк.
раскрыть ветку (1)
0
Автор поста оценил этот комментарий
У нас же 1С, конфигурация на сервере, просто создается новый документ или справочник
показать ответы
10
Автор поста оценил этот комментарий
У меня взбомбило сразу после прочтения первого кейса!
Есть поговорка «семь раз отмерь, один раз отрежь». Сотрудник предлагал рабочее решение, учитывающее все требования к функционалу. Разница в трудозатратах ну совершенно незначима по сравнению со сраным экселем.
В этом случае, деливери менеджер (или РП) принял решение к реализации после которого, многократно возрастет время на поддержку и разруливание этого говна.
Грамотных руководителей вообще-то учат риск-менеджменту по серии ISO:9000, а также для определения рисков при принятии решений есть отдельная нотация (матрица рисков).
В данном случае, это не перфекционизм сотрудника, а желание сделать правильно с первого раза.
А менеджер просто «карьерный жополиз», который обязательно отчитается высшему руководству об успешно выполненной работе в срок, а потом будет бегать как ошпаренный «спасите-памагити» (вместо того, чтобы попытаться выделить дополнительное время).
Решение принято херовое, я бы вообще поставил вопрос о компетентности такого менеджера.
раскрыть ветку (1)
0
Автор поста оценил этот комментарий
Знаешь, время на поддержку и разруливание не возросло, заказчик был доволен. А лучшее - враг хорошего. Разница во времени реализации была в 5 раз, это существенно.
показать ответы

Темы

Политика

Теги

Популярные авторы

Сообщества

18+

Теги

Популярные авторы

Сообщества

Игры

Теги

Популярные авторы

Сообщества

Юмор

Теги

Популярные авторы

Сообщества

Отношения

Теги

Популярные авторы

Сообщества

Здоровье

Теги

Популярные авторы

Сообщества

Путешествия

Теги

Популярные авторы

Сообщества

Спорт

Теги

Популярные авторы

Сообщества

Хобби

Теги

Популярные авторы

Сообщества

Сервис

Теги

Популярные авторы

Сообщества

Природа

Теги

Популярные авторы

Сообщества

Бизнес

Теги

Популярные авторы

Сообщества

Транспорт

Теги

Популярные авторы

Сообщества

Общение

Теги

Популярные авторы

Сообщества

Юриспруденция

Теги

Популярные авторы

Сообщества

Наука

Теги

Популярные авторы

Сообщества

IT

Теги

Популярные авторы

Сообщества

Животные

Теги

Популярные авторы

Сообщества

Кино и сериалы

Теги

Популярные авторы

Сообщества

Экономика

Теги

Популярные авторы

Сообщества

Кулинария

Теги

Популярные авторы

Сообщества

История

Теги

Популярные авторы

Сообщества

Недвижимость и ремонт

Теги

Популярные авторы

Сообщества