До сих пор в блоге я почти не касался вопросов, связанных с организацией процесса разработки софта. Мне есть, что сказать по этому поводу, благо я видел этот процесс с разных сторон: разработчика, проектировщика, руководителя отдела. Это первая статья в категорию "Управление", которая посвящается таким вопросам. Надеюсь, это все будет полезно и программистам, и начальникам, и заказчикам, и возможно будет как-то содействовать уменьшению непонимания, существующего между ними.
Знакомая ситуация: начальник обращается к программисту с предложением (требованием, угрозой — нужное подчеркнуть :-) ) реализовать какую-нибудь нужную вещь в системе, на что тот, не долго думая, отвечает: "не, это сложно..." Тут же возникает конфликт, потому что начальнику эта самая вещь кажется далеко не такой сложной, и он подозревает, что программист просто ленится.
Ситуация эта, вопреки бытующему мнению, не является никаким "необходимым злом" в общении с программистами и вполне разрешаема.
Но начать я хочу с выяснения того, что такое на самом деле "сложно". Я готов предложить очень простое формальное определение этого понятия.
Определение
Сложно — это то, что ваш программист называет сложным.
Легче не стало :-). Но это ведь формальное определение, а оно всегда нуждается в дальнейших разъяснениях.
Что это определение подразумевает в первую очередь — это то, что сложность невозможно померять объективно в каких-то взвешенных единицах. Это всегда субъективное понятие. Для программиста графических интерфейсов задача подвешивания к веб-сайту RSS-потока включает знакомство с другим языком программирования, чтение статей "что такое RSS", потом "что такое XML", потом "как делать XML в PHP". Это сложно. Веб-программиста это займет на какой-нибудь час, потому что та бибилиотека, с которой он работает, содержит волшебную функцию "повесить RSS-поток на сайт", и он про нее знает (час уйдет на уточнение того, что же именно будет в потоке, и где же именно разместить иконочку). Кроме специализации огромное значение имеет авторство кода. Починить свой баг на порядок проще, чем чужой, даже если они из одного и того же раздела программирования.
Само слово "программист" в определении тоже имеет смысл. Большое заблуждение многих заключается в том, что программирование — это такая же работа, как, скажем, бухгалтерия, и любой человек может быть программистом, если прочитает несколько умных книжек и потренируется. На самом деле это не так. Способность программировать — это своего рода талант, который можно сравнить со способностью рисовать картины.
Любой человек может изучить технику академического рисунка, и рисовать он будет гораздо лучше, чем мы с вами, но вот художником он от этого не станет. Аналогично, та сложность, которую программист способен прикинуть по формулировке задачи, сильно отличается от той, что видна другим. А случаи, когда задача в реализации оказывается еще сложнее, гораздо более часты, чем обратные.
Впрочем, многие в это не верят, считая такую позицию просто попыткой набить себе цену :-). Переубеждать не буду. Во-первых, надежно это можно сделать только переставив свои мозги оппоненту, а во-вторых, это не так уж и важно для предмета разговора. Двинемся дальше.
Дальше все проще. "Сложно — это то, что ваш программист называет сложным." Это означает, что раз работу выполнять именно ему(ей), то его(ее) мнение и является определяющим. Да, возможно вам задача кажется простой. Да, возможно вы убеждены, что ему(ей) просто лень подумать. Да, возможно вы считаете, что ваш программист уже полтора года применяет не те языки, библиотеки и фреймворки, и вообще в .NET (J2EE, ASP, SAP — любимое подчеркнуть) все это работает само. Это, очевидно, не имеет ровно никакого значения, потому что ваш программист умеет то, что он(она) умеет, а вы не возьметесь программировать вместо него(нее).
И маленькое дополнение: если вы скажете ему(ей) о том, что его(ее) инструменты — отстой, это не будет являться дополнительной мотивацией.
Чаще всего, на самом деле, имеет место и то, и другое: и задача сложней, чем кажется, и у программиста мозги заняты совсем другим. Вот это и есть — практическая сложность. И ее надо решать.
Решение задачи
Начну с того, чего делать не надо. Не надо пытаться на програмиста давить, заставлять чувствовать себя виноватым, взызвать к чувству ответственности и т.д. Любому человеку с интеллектом все эти "хитрости" и "приемы" из бульварной литературы типа "Как управлять людьми" слишком очевидны. Нормальный программист просто расстроится, потому что знает, что нельзя заставить мозг работать по-другому, а плохой программист будет старательно делать вид, что он ринулся в бой, но результата из этого не получится (совет: если ваш программист плохой, увольте его, никаких других способов это исправить нет).
Вместо этого надо добавить к вопросу еще одну метрику помимо сложности — важность. По личному опыту скажу, что часто программисты, отвечая на вопрос "а не сложно ли будет...", отвечают на уже следующий вопрос: стоит ли важность задачи времени на ее реализацию. Многие программисты считают (и часто вполне обосновано), что достаточно хорошо представляют себе общую ситуацию, чтобы сразу сделать вывод об общей целесобразности работы. И этим ответом просто стараются сэкономить всем время.
Но часто они ошибаются. Поэтому надо явно попросить программиста оценить именно сложность, в отрыве от всего остального, выразив ее в самых понятных единицах: часах работы. Причем, надо быть готовым к тому, что сама оценка тоже займет время, и потребует множества уточнений условий. Больше того, если в ответ вы услышите что-то вроде "ну... (пауза 2 сек.)... неделя где-то", то это оценка не срока, а строгости выражения вашего лица. Сделайте доброе лицо и попросите программиста все же подумать как следует денек-другой, как это будет реализовываться, все посчитать, и сказать, сколько займет часов.
И последнее замечание. Задача программиста — программировать. А организовывать процесс программирования, в который входит и взаимооценка сложности с важностью — это ваша задача, дорогие руководители.
Комментарии: 17
Золотые слова. Особенно про важность.
В фортунки :)
5 баллов за заметку. Просто в тему!
Особенно о том, что программист должен программировать, а руководитель организовывать (а не постоянно дергать и мешать процессу).
Спасибо !!!
Отличная статья. Добавлю в своих закладках, а ваш блог в свой блогролл. Во всех проектах бывают такие ситуации. И решить их может только сплоченость и доброжелательность всей команды.
Извечная проблема между менеджером (руководителем) и программистом :)
Моя цель как раз показать, что все "извечные" проблемы решаются при желании. "Извечными" они бывают только тогда, когда хотя бы одна из сторон свято уверена в своей правоте и не хочет ничего менять.
Во! Идея: написать драматическое прозведение про двух программистов - одному все давалось легко: за что ни возьмется - пишет играючи, талантливо, да так что у работодателей дух захватывает. И ведь не учился особо ничему, но все дается ему без усилий.
Так что и времени на развлечения много остается, и зарплату ему регулярно повышают.
Второй программист (например ведущий, с большим опытом, в летах и при регалиях) совсем наоборот - долго мучается, вымарывает строчки кода из готовой программы, не спит (по ночам выдумывает новую архитектуру), страдает несварением желудка..
Наука программирования дается ему тяжким трудом, нет времени на развлечения - все уходит на то чтобы "гармонию алгеброй поверять"...
И вот заела его глубокая и мучительная зависть к первому, молодому программисту.
Дескать, где же справедливость? Где ж правота, когда программерский священный дар, бессмертный гений — достался не в награду за изучение паттернов, XP и разных модных фреймворков, а озараяет голову этого гуляки?
И решил он его подсидеть. Пошел к работодателю, вспомнил все аргументы, которые 18 лет копил по такому случаю, приврал немного, да и выставил молодого в черном свете...
Вот встречаются они как-то в пабе - молодой программист хмурится, не весел.
- Что так? - Спрашивает ведущий.
- Признаться, документация меня тревожит.
- Давно ли пишешь?
- Давно, недели три. Но странный случай...
Дальше молодой программист рассказывает ведущему как получил странный e-mail от работодателя, в котором тот просил его задокументировать систему.
- А правда ли, что (такой-то) кого-то подсидел? - Спрашивает молодой.
- Да не, не думаю: он слишком прост.
- Он же гений, как ты да я. А гений и злодейство —
Две вещи несовместные. Не правда ль?
- Ты думаешь? (посылает работодателю смс в которой описывает пьянство молодого в рабочее время)
- Ну, пей же...
Программисты-моцарты и программисты-сальери? ;)
Мда, если бы это было иммено так, то софтверная индустрия загнулась бы еще годах в 70-х, по причине нехватки талантов.
Конечно лестно думать что программист это творческая профессия, я даже соглашусь что элементы творчества таки в ней присутствуют, но все же не нужно сравнивать сугубо инженерную специальность с Даром Божим :)
Хотя не секрет что хороший программист работает на порядок (а то и на два) лучше чем плохой. В смысле напишет тот же код быстрее и с меньшими ошибками (синтаксическими, логическими, ошибками в архитектуре). Но я бы скорее отнес это не к таланту, а к опыту и способностям (ну и образованию разумеется, хотя некоторые компенсируют его опытом).
Считать ли программирование искусством — это очень большая отдельная тема :-)
Я не вижу противоречий :-). Давай переназовем то, что я назвал "талантом", в "способность". Гораздо менее романтично, но суть та же. Но эта природная данность составляет только часть профессии. Дальше надо учиться и работать, хотя все и делают это с разного уровня. Но начальный уровень-то есть, что ж в этом странного?
С этим я как раз не спорю :)
В твоих словах, как мне показалось, проскользнул некий намек на элитарность одних и обреченную серость других - которым Бог не дал талан.. способностей.
Ну, значит показалось ;)
А вот это, по моему опыту, гиблое дело. Заставить программиста оценить в часах свою работу практически невозможно, не только вследствие лени (отличающей, наряду с большим самомнением, хороших программистов ;), но imho просто не существует адекватных методов такой оценки.
Ну не на скорость кодирования же (в знаках в минуту) ориентироваться, в самом деле :)
Получается как в анекдоте: "ну неделя.. максимум две!"
Хм... Да, так и есть. Я опять не понимаю, где противоречие :-). Я пишу, что уровень разный, и дальше надо работать. Но также полно людей, у которых этих талантов/способностей просто нет. Также как у меня нет таланта, скажем, баскетболиста.
Но причем тут элитарность-то?
Абсолютно не так :-). Развенчанию этого мифа я посвящу следующую статью в категории "Управление". Как раз сейчас я заканчиваю проект, в котором план на два месяца и 9 дней совпал с реальностью с разницей дней в 3-5.
Вот общая (работающая) теория: http://joelonsoftware.com/articles/fog0000000245.html
Я даже пытался делать это в рамках нашего с тобой бывшего общего места работы. Это не работало, потому что все усилия по планированию легко перечеркивались директивами свыше (ну ты помнишь: "это срочно, но предыдущие задачи тоже не отменяются").
Да, да, знаком :) Как раз сейчас у меня есть такой план. В общем и целом он позволяет отслеживать текущую ситуацию, и я даже готов допустить что оценка возможна когда единственный исполнитель это я ;)
Когда в команде несколько человек и существуют связанные задачи, использовать этот метод становится гораздо сложнее. Именно потому что оценка должна исходить от непосредственных исполнителей, а они ленятся и/или не обладают достаточной квалификацией, чтобы точно оценить время.
Хотя возможно это просто проблема мотивации ;)
Ну, это-то как раз не проблема - новая задача просто вносится в план, в графу "непредвиденные задержки" - иногда достаточно показать как это отражается на сроке проекта, как срочность быстро пересматривается :)
Часто бывает и так что эта "срочная" задача в итоге оказывается никому не нужна (у меня есть парочка таких "срочных" задач, месяца два уже как пофиксены, никто не вспоминает).
Так что в успехе планирования адекватная оценка приоритетов не менее важна чем оценка сложности ;)
Мой опыт говорит, что это в первую очередь проблема тренировки. Это действительно трудно, и получается далеко не с первого раза. И еще очень важно оказывать доверие исполнителю. А если глумиться над ним в духе "опять ты ничего не успел", то конечно он ничего больше не захочет.
Хорошо, если так :-). Я помню, ничего не пересматривалось даже в этом случае, потому что "бизнес не может ждать".
Точно!
Ну дык он ведь действительно не может ждать ;)
В данном случае сказывается специфика нашего процесса разработки - в случае аутсорсинга список требований тоже меняется, но гораздо реже чем при поддержке одной постоянно развивающейся собственной ИС.
Просто нужно выбрать наиболее подходящую гибкую методологию ;)
Вот, кстати, набрел на сходную дискуссию :)
Хотелось бы отметить еще один момент. Я к сожалению не работал в софтверных компаниях, где производство софта, надеюсь, это нормально организованный рабочий процесс. В нем, наверное, программист занимает одну из нескольких позиций. Может быть и не самую важную, вернее, не Единственно важную. Выше же сказанное, в первую очередь, относиться к работе фрилансеров, да программистов в разномастных бизнес-учреждениях. А в них действует одно правило "если нужно, то вчера". Талант программиста - талантом, но и результативность должна быть. Если ты работаешь один, то вряд ли встает вопрос о каком-либо таланте. Работаешь и все. На сегодняшний день "своего рода талант" должен присутствовать у любого работающего человека. Но на мой взгляд это скорее склонность, тяга заниматься любимым делом. А не просиживать штаны. Лично я бы сегодня, с подозрением относся к человеку, про которого мне сказали - "он талантливый программист". В лучшем случае окажется не очень обиженным хакером и все. Профессионализм на мой взгляд намного важнее таланта. А вот большинтсву боссов, как-нибудь вживить талант руководителя очень бы хотелось. Я сам всю жизнь отработал в конторках. По моему убеждению, их руководителей в 100% случаев вообще не волнует какими средствами, технологиями, усилиями и Реальной работой выполняется разработка нужных им программ. Чаще всего эти люди предполагают, что постановка задачи в форме "мне нужна база данных" собственно и решает задачу. Поэтому ответ "сложно" рассматривается как нежелание работать. Хотя если разобраться, это просто нежелание платить за работу достойные деньги. Кроме того, замечал даже за собой, что когда я говорю "сложно" у меня в голове уже есть перечень действительных сложностей - например "работа с чужим кодом, недостатки архитектуры, отсутствие готовых библиотек". А для босса/заказчика ответ "сложно" - слишком "общо". И ничего само по себе не значит. Действительно, когда лично тебе придется решать задачу - то вся нагрузка и ляжет только на тебя. Т.е. тут надо согласиться с тем, что "сложно" - субъективное мнение отдельного исполнителя. А для того, чтобы разрулить непонимание, между боссом и программистом должно быть обычное доверие. Что опять таки практически не реально, за исключением если программист не состоит с ним в тесных родственных связях. Словом, проблемы реакции на ответ "сложно" - просто проблемы отношения 2х людей. И никакого реальной связи с программированием даже и не прослеживается. Просто обсуждайте задачу подробно. Не можете сделать это во время личной встречи, подготовте записку с изложением трудностей, т.е. этапов решения сложно задачи. Укажите на существующие, известные вам ограничения технологий/архитектур, возможно решение упростится. Тем более, что от сложной работы никто и не отказывается. Главное чтобы она была интересной и хорошо оплачиваемой. Либо пусть ее делает талант.
Ха-ха-ха! Это вы наверное про администратора а не про программиста?
Статья интересная, но комментарии еще интересней :)
Вот у меня сейчас проблема возникла. Мы ведем разработку на довольно редкой платформе (не спрашивайте какой) и народ подался за длинным рублем в другие страны. Шеф говорит, что давай скорее набирать новых программеров хоть каких, лиж бы отдел не расформировали.
Вот и взяли на довольно сносную ЗП человека по принципу испытательный срок покажет кто такой.
На собеседовании вроди и знания показал и тестовые задачки решил.
Начали работать - проблема. Дашь задачу, что-то делает, делает, потом окажется то плохо спроектировал, то откровенно плохой алгоритм применил, сложно развиваемый. Начал я с ним парным программирование заниматься. Вижу, что тормозит пацан откровенно, ну принялся я за ним присматривать, решения подсказывать, советы давать, вроди худо-бедно, да движется проект.
Но вот напасть новая настала - начал время затягивать: то по интеренту шарится, а потом говорит что не успевает, то что-то делает, а результата нет, пока я сосвоим решением не припрусь.
Поставил вопрос о замене специалиста, говорю надо бы лучшего нам. А мне в ответ - а где возьмешь, мы конечно поищем, а вы давайте там нам план выполняйте и все такое.
Вот казалось бы, помогают тебе - УЧИСЬ и получай опыт. Так нет - лень и интернет дороже.
Как вообще в такой ситуации заставить программера работать. Отчеты почсовые с последующим моральным давлением применить???
Может кто чего посоветует?
PS. Увольнять нельзя
Именно советовать трудно, потому что такие ситуации обычно только кажутся понятными, а на самом деле там полно всякой специфики, которой в комментарии на блоге не видно. Но тем не менее :-).
Я придерживаюсь точки зрения (которая подтверждается моей практикой), что программиста нельзя заставить работать. Никому не нравится, когда их к чему-то принуждают, а програмисты еще к тому же и считают себя слишком умными (и часто — заслуженно), чтобы им "кто-то там" что-то указывал.
Но есть вариант попробовать его заинтересовать работой. Правда, это может пройти только если он в принципе "болеет" программированием как таковым. Если же он пошел в программинг только потому что сейчас зарплаты высокие, то это потеряный случай, и надо просто планомерно терпеть и искать замену.
Если же он все таки нормальный программист, то надо разобраться, что ему интересно и что не нравится. Возможно это не его лень виновата, а какие-то внешние условия. Возможно стоит проанализировать, почему уехали предыдущие программисты, чего у вас нет, что есть там. Программистов очень часто привлекают вещи, которые просто невдомек традиционному менеджменту:
Другими словами, если у программиста есть какая-то "странная дурь", которая всем вокруг кажется статусной привелегией, обычно ее гораздо дешевле удовлетворить, чем платить зарплату человеку, который не работает. Хотя это, конечно, дороже, чем просто ввести "почасовой контроль", но такие вещи просто не помогают. Но, обязательно повторюсь, это все работает только для программиста, который хочет и любит программировать.