DataLife Engine > Блог > Программисты тоже люди

Программисты тоже люди


2-02-2015, 09:57. Разместил: admin
Всегда кажется, что программисты себе на уме. Совсем не понятно, что они делают, как делают. Более того, их можно назвать даже странными. Но, все же, программисты тоже люди и в процессе работы не раз сталкиваются с рядом «человеческих» проблем. В основном это происходит из-за непонимания заказчиками, руководителями работы программиста. А ведь и те и другие, как белки в колесе, делают свою работу и должны четко понимать в необходимости друг друге.
 
Попробуем немного раскрыть некоторые моменты, которые подскажут, как помочь программистам понять, что нужно вам, как пользователям их услуг, и не выглядеть в глазах разработчика обузой. Как сделать общение с заказчиком более понятным.

 

 


Сроки, как главный раздражитель

 
Очень часто заказчик задает вопрос: сколько займет времени сделать эту подсистему, раздел, обработку, отчет? А из вводных данных дается, так сказать, техническое задание из пары строк теста. Просят назвать срок, не осознавая, что неизвестна ни задача, ни требования, только одно предложение, которое, в принципе, можно затем перерасти в приличное техническое задание. И когда заказчик настойчиво просит назвать точные сроки данной неизвестности, чтобы хоть что-то сказать, озвучивается срок «с потолка». А как иначе? Назвать срок, впервые столкнувшись с проблемой, даже если она по-жизни встречалась разработчику, это просто не реально. Если разработчик готов назвать какой-либо срок, то к этому сроку однозначно нужно прибавлять минимум в два-три раза количество времени. Ошибкой будет со стороны разработчика недооценить, а со стороны заказчика его работы — надеяться, что успеет в срок.

В сжатые сроки разработчик будет настолько пытаться уложиться в них, что будет игнорировать многие вещи, которые возможно будут гораздо больше необходимы для проекта. А впопыхах такое видение просто будет не замечено. Так стоит ли спешить? Возможно ли, сконструировать модель по одному предложению? Не стоит искать виновного в том, что сроки указаны неверно. Вина будет программиста, если он не потрудился уточнить детали у заказчика, и называет сразу ему срок (и цену).

Работа по заданию с одним неизвестным  — вроде как ответить на вопрос
«сколько времени займет покрасить забор, в которой периметр не известен?».

 


Обещание

 
И после этого всего программисту будет задан вопрос: «ты же обещал (!) сделать за два дня, а прошла неделя!».
 
Сроки разработки реальных подсистем чаще всего всегда дольше запланированных согласно статистике. Непредвиденные изменения в процессе работы, которые 100% возникнут и которые никто не учитывает. Срок, данный в техническом задании (ТЗ), сроком вообще нельзя считать. В ТЗ следует указывать планируемый срок начала тестирования! Именно тестирования или показа результата работы, готовности определенного этапа.

Напирая на этот срок, заказчик (например, менеджер) демотивирует и дестабилизирует программиста. Особенно когда из-за этого менеджер не выполняет свою работу и свои косяки валит на него. Это совершенно неверный подход. Такое ощущение складывается, что именно программисту нужно, чтобы та или иная система работала (!). Поверьте, программисту это уж точно не нужно. Да, несомненно, это его заработок либо должностные обязанности, но в целом то, смотря правде в глаза, это ведь нужно именно тому, кому это нужно — тому кто заказал разработку.
 
«Большинство программистов – оптимисты. Болезненный опыт может умерить оптимизм, но до его приобретения присутствует склонность к оптимизму. Пессимисты в команде часто не пользуются популярностью, даже если они оказываются правы. Мало кто будет рисковать репутацией и идти против большинства без очень серьезной для этого причины. При том, что проблемы часто дают о себе знать как „Мне это не нравится, , но я пока не могу объяснить почему", и с такой аргументацией редко удается выиграть спор»
 

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

Программист сравним с космонавтом, который высаживается на луну. Всю конфигурацию он физически не может знать. Он может «высадиться» в ту или иную обработку и посмотреть проанализировать, как она работает. И каждый раз для себя будет узнавать много нового. Хорошо, если сможет разобраться быстро. Не у каждого квалификация это позволяет.

Вот вы, например, все ли знаете по своему участку работы? Разве можно все знать? Также будете искать ответы, обращаясь к интернету, прочим источникам информации, другим специалистам. И абсолютно не факт, что сможете найти требуемое.

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

 


Чем не художник

 
Не редкая ситуация, когда заказчик приходит и просит: «глянь срочно, тут надо за час сделать отчет!». Дается образная картина, что требуется. Не учитывается, что работа программиста тождественна с работой художника. Он максимально фокусируется на одной задаче! Так же как художник  — на всех деталях картины, и держит в голове все. Не менее 20 минут требуется, чтобы вернуться в состояние «потока», когда отвлекли. У кого-то даже и больше. Отвлечение очень может раздражать. А особенно когда требуется программисту «очень быстро и срочно» отвлечься на чужой (типовой) код, который требует иной раз огромное количество времени для анализа. Это никто не любит.

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

 


Контроль

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

Быстрее

 
А давайте еще больше поставим в условия срочности: «мне это нужно сегодня!». У программиста ничего не остается, как сделать по-быстрому и стройный циклический идеальный граф зависимостей всегда ломается с новыми «бизнес-требованиями». При таких условиях очень много появляется «грязного» и некрасивого кода. Это меньше всего нравится даже самому программисту. И когда не дают времени на то, чтобы к нему вернуться и переписать нормально. Результатом этого могут возникнуть блокировки в базе, отчет будет выводить данные очень и очень долго. Кому от этого будет хорошо?

Со временем плохого кода становится так много, что не стоит удивляться, когда приходит другой программист на место старого и будет утверждать, что так делать нельзя было. Поверьте, все так программисты будут говорить!
 
При таком подходе проект может просто не дойти до конца. Возможно, проще переписать с нуля, что вызывает большое неудовольствие заказчиков. Хотя, если задуматься, кто в этом виноват?… Мы не обвиняем во всем заказчиков. Есть и такие программисты, которые совсем не теми способами все делают, не хватает квалификации. Для этого пригласите другого специалиста, который сможет подсказать и направить на нужный путь. В конце концов, отправить на курсы повышения квалификации не помешает. Были бы еще курсы по тому, как правильно давать задания. Это тоже искусство. Не каждому дано. Вот и получается «слепой» с «глухонемым» общаются.

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

Периодически следует возвращаться программисту
к своему ранее написанному коду.
 
И для этого ему следует выделять время.

 


Удобство – вещь необходимая

 
Юзабилити (удобство работы в интерфейсе) всего проекта  — это особая работа, и ее должны делать профессионалы, которые обладают необходимым умением и практическим опытом. Уметь сверстать так, чтобы везде было одинаково и в одном стиле, это мастерство! Программист, не всегда понимает как заказчику нужно, чтобы выглядело в конечном виде. Возможно, функционал внутри будет соответствовать тому, что нужно. Но вывод результата на экран может не удовлетворять в корне. Требовать это от программиста – технического специалиста не благоразумно. Все равно, что автослесарю взять и заказать сделать скульптуру.

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

 


Вывод

 
Лучший способ контролировать и правильно организовать работу с программистом, это сделать его подконтрольным менеджеру проекта, который будет разбираться в технических моментах, и быть наравне с его мировоззрением. И ни в коем случае не стоит заваливать кучей требований и все сразу, а также тянуть со всех сторон, как это происходит в басне «про лебедь, рак и щуку». Чем больше будете на него давить, тем меньше он сможет вам помочь. Именно помочь! Ведь это вам нужна его помощь, иначе бы не требовали от него.

Интеллектуальная работа поглощает не меньше энергии, чем физическая. А калорий тратится иногда гораздо больше. Программист (архитектор/аналитик)  — это личность творческая, его нужно направлять. Нужно ставить приоритеты и участвовать в процессе, помогать ему, тем самым помогая себе.

Как хорошо вы относитесь к программистам? Насколько реально они помогают вам в вашей работе? Вы постоянно их ругаете за постоянные ошибки в их работе? А сколько хорошего они сделали?
 
Вы просто не представляете что может сделать хороший программист в программе, если действительно он будет обладать необходимыми навыками, знаниями, умением и главное желанием. Так помогите ему в этом и вы поможете прежде всего себе.
 

Анекдот напоследок:

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

 — Вы находитесь на воздушном шаре в 30 футах от поверхности Земли, между 40 и 41 градусом северной широты и между 59 и 60 градусом западной долготы ответила женщина.  
— Вы, должно быть, программист?  
— Да, а как вы догадались?  
— Вы мне дали абсолютно точный ответ, но я совершено не представляю, что делать с этой информацией, и я всё ещё потерян. Откровенно говоря, вы мне совершенно ничем не помогли.  
— А вы, наверное, менеджер?  
— Да. А вы как догадались?  
— Вы не знаете, где находитесь и куда направляетесь. Поднялись вы туда, благодаря воздуху. Вы дали обещание, которое не представляете, как выполнять, и ожидаете, что люди, которые находятся ниже вас, решат ваши проблемы. И, наконец, сейчас вы в том же самом положении, в котором находились до встречи со мной, но почему-то теперь в этом оказалась виновата я»


 

<< Особый случай. Внедрение или установка?    Далее: Первое знакомство с разработчиком >> 



Хаки для Dle 10.4
скачать форекс советники Ilan

Вернуться назад