Что измерить?
Позвольте быстренько пробежаться по такой, на первый взгляд эфемерной, и в то же время вполне осязаемой составляющей работы программиста как скорость работы, ну, или производительность труда. Для многих профессий этот параметр довольно очевиден и часто является прямым способом оценки трудозатрат, а соответственно и размеров оплаты труда. Начиная от кладки кирпича и заканчивая текстами сценариев к сериалам мы имеем дело с относительно легко сопоставимыми количеством и трудоемкостью.
Одно дело, конечно, стройка складского помещения и совсем другое футеровка доменной печи. Нельзя сказать что и сценарий современного сериала меньше проработан, чем отдельное художественное произведение, и работу авторов нынешнего HBO сложно поставить рядом с творчеством авторов мексиканских мелодрам прошлого столетия. Тем не менее, если отбросить качественную составляющую, то производительность одного среднего каменщика или сценариста число с довольно таки малым разбросом. Даже самый опытный каменщик не разовьет скорость превосходящую в несколько раз скорость работы новичка. Есть физический предел. Никакой сколь угодно талантливый сценарист не сможет выдавать по десять серий в неделю.
Если убрать за скобки качество продукта, то и с программистами теоретически можно поступать примерно похожим способом. Количество строчек кода, количество коммитов, количество закрытых задач, количество сданных проектов кажутся именно теми показателями, которые можно условно обозначить скоростью. Часто в общем так и поступают. Другое дело действительно ли такая скорость соответствует фактическому результату. Если бригада каменщиков кладет кирпичи со скоростью три кубометра в день, то за пять рабочих дней эта бригада выложит стену объемом 15 кубометров. Ни больше ни меньше. И ее будет видно. Сценарий для одного эпизода придется снабдить достаточным количеством сцен и диалогов, что бы актеры не делали сложные щи молча на протяжении часа.
Так вот с исходным кодом все чуточку сложнее. Если мы измеряем просто количество смердженных строк, то я вам скажу, да вы и сами знаете, что налить воды в исходники можно сколько угодно. Вообще сколько угодно. Причем уверяю вас, в исполнении отдельных персонажей выглядеть это будет настолько замысловато для стороннего наблюдателя, что не вызовет никакого сомнения в необходимости каждой строчки. Обнаруживается вода в значительной мере только в результате длительной поддержки такого кода и при радикальном рефакторинге. Большинство исходников, глубокую ревизию которых мне приходилось проводить, в том числе и своих, можно сократить вдвое, втрое, многократно.
Важно понимать, что рефакторинг сам по себе никак качественно не меняет работоспособность программы как таковой. Если по пути и обнаруживаются не самые оптимальные моменты, то это никак не зависит от количества строк кода. То есть в отличии от каменщика программист запросто может сделать стену полой и никто, по крайней мере сразу, не догадается куда делись недоложенные кубометры кирпичей.
Это с одной стороны. С другой, если мы решим вывести хитрых программистов на чистую воду и попытаемся оценивать их работу по закрытым проектам и полноценным задачам. То придется озаботиться тем, что бы над каждой задачей провести подробнейший анализ, составить доскональное техническое задание, составить тесты. Грубо говоря составить детальную смету. Так, что бы заказчик уже сам знал, сколько времени нужно что бы спроектировать базу данных, реализовать ту или иную функцию, нарисовать форму, составить отчет.
И даже при этом ушлый разработчик обязательно найдет и вполне аргументированно покажет, что вот в этом месте не все так просто и надо бы накинуть сверху. Что бы опровергнуть тезисы жадного программиста придется либо привлекать настолько же квалифицированных специалистов, либо самому вникнуть в проблему настолько, что можно будет настоять на альтернативе. Все может закончиться тем, что заказчик уже сам будет способен разработать программу так как ему надо. А деньги и время уже потрачены.
Работает это все и в обратную сторону. Жадный работодатель может занижать фактические трудозатраты аргументируя это тем, например, что вот программист А сделал похожую задачу за день, а вы товарищ Б мучаетесь с ней неделю, почем зря, потому что платить я вам буду по результату. То что программист А при этом обеспечил головную боль для десяти последующих программистов, которые будут вынуждены по кирпичикам перекладывать всю стену, работодателя не особенно волнует. Могу даже сказать, что так оно работает куда чаще чем наоборот.
В чем измерить?
Халтура со стороны разработчиков и несправедливая эксплуатация явления связанные, и, разумеется, не только в программировании. На отвали может работать и каменщик, и сценарист, и даже врач, и физик ядерщик. Пытаться заплатить меньше будет эксплуататор всегда и в любое время. Это такая своеобразная ползучая война. Разница лишь в том, что у стюардесс, грузчиков, металлургов и ученых она идет уже достаточно давно. Демаркационные линии довольно четкие. У работников есть профсоюзы, у работодателей есть рынок труда. Работодатель угрожает сокращением и увольнением, работник - бойкотом и стачкой. У программистов в этом отношении пока все еще впереди, но общая тенденция все же намечается.
В реальных отраслях народного хозяйства существует эдакий рыночный способ определения стоимости и оценки трудозатрат. Объявляется конкурс на то что бы, скажем, выложить стену с такими-то размерами, такого-то качества к определенному сроку, за некую начальную оплату. Если кто-то готов сделать дешевле - пожалуйста. В общем и целом сейчас такой моделью пытаются воспользоваться во всех областях экономики. Казалось бы, и волки целы и овцы сыты. Хотя как мы можем видеть, доводит это и до крайностей, когда, например, таксисты работают по 24/7 на такого же состояния автомобилях. Но вот в программировании это кажется действительно довольно годным подходом. По крайней мере на этой стадии войны.
Есть задача. Есть энное количество желающих заработать. Каждый оценивает самостоятельно за сколько времени или денег он готов воплотить задачу в жизнь. Есть и проблемы связанные с качеством при таком подходе. Стоит вопрос и того что же делать, если исполнитель переоценил свои силы. Но все эти проблемы и вопросы каким-то образом разрешимы, в частности юридически.
Если и заказчиком и исполнителем выступают не отдельные одиночки и энтузиасты, а крупные компании, то и вопрос с неверной оценкой сил в общем не стоит. Юристы заказчика не дадут сильно отходить от договоров, а крупный коммерческий производитель ПО всегда найдет нужные и компетентные кадры в достаточных количествах. Практически идеальная модель.
То есть, рецепт простой. Составляем какое-то техзадание и даем уже исполнителям самим оценить затраты. По пути можно уточнять задание, менять суммы, двигать сроки, но по итогу приходим к согласию. То как потом исполнитель извернется, где найдет программистов, как их будет стимулировать, наймет ли одного гуру или двадцать индусов, заказчика интересовать не должно. Контора исполнитель может дальше масштабировать задачу и выступить в качестве заказчика уже для конкретных наемных программистов. То есть все как у взрослых. К сожалению, на практике не все так гладко и по-взрослому.
Скорость обучения
Проблемы начинаются, когда и заказчик и работодатель это одно и то же лицо, а исполнитель не специализированная контора, а IT отдел банка, фабрики, аэропорта, больницы. Во-первых, в таких ситуациях большинство задач специфичны для конкретной организации и ситуации, в которой она находится. Нет сметного справочника ГЭСН по всем видам задач программирования. Во-вторых, нет строгого критерия квалификации программиста. В-третьих, как правило выбор кадров сильно ограничен. В-четвертых, сам персонал часто не имеет практики самостоятельной оценки собственного труда. Нет смысла устраивать конкурс на создание веб-сайта между двумя программистами, один из которых работает с бухгалтерией, а другой с торговыми терминалами.
Прозвучит для некоторых странно, особенно для работодателей, что в таком случае скорость измеряется вовсе не в человекоднях на решение задачи, а во времени и затратах на обучение. Курсы ли это будут повышения квалификации, самостоятельное ли образование это уже зависит от ситуации. Но, то сколько на это потребуется времени и денег, грубо прикинуть можно. Не последнюю роль тут как-раз может сыграть бэкграунд конкретного сотрудника. Подробнее об этом было сказано в одной из предыдущих заметок.
Даже если на предприятии нашелся человек в принципе знакомый с поставленной задачей, имеющий кое-какой опыт работы, то оценка трудозатрат все-равно не его основной козырь. Если этот человек никогда не зарабатывал фрилансером или не имел собственного софтверного бизнеса, то он почти никогда не угадает со сроком сдачи. Его личный опыт слишком ограничен для таких оценок. Опытный печник наверняка справится и с кладкой стен из шлакоблока, но оценить за сколько он сможет выложить коробку дома полностью он не сможет пока не попробует. Причем наверняка ошибется он и с оценкой сроков для второго дома с несколько другой планировкой.
Практическим советом в таких случаях я бы назвал честность. С обоих сторон. Исполнитель должен прямо сказать, что время в основном будет потрачено не на непосредственную разработку, а на, например, прочтение книжек и практические занятия. Работодатель же должен отдавать себе отчет в том, что быстрее и дешевле будет выкупить платный недельный курс по строительству сайтов, чем ждать когда сотрудник начитается и набьет себе руку. Ведь не известно еще с каким результатом это у него получится. Более того, дорогой курс с сертификацией и аттестацией
позволит работодателю в дальнейшем требовать определенного уровня качества.
Однако все это прекрасно выглядит когда это какая-то новая задача. Ну, то есть, когда есть определенное задание, когда есть рассчитанный экономический эффект, когда заведомо известны приемлемые сроки и суммы. На практике таких задач возникает одна на десять, если не реже. Потому что чаще всего программист занимается не разработкой, а банальной поддержкой чего-то существующего. А в таком случае говорить об оценке производительности труда не получается ни так, ни сяк, ни эдак.
Скорость чтения
Классическая задача стоящая перед среднестатистическим программистом IT-отдела автоматизации максимально скучна и при этом на столько же не поддается квантованию. Не знаю, что-то типа добавить еще поле к отчету, или в стиле - а давайте здесь приделаем волшебную кнопку которая делает хорошо. Причем приделать поле к отчету может оказаться отнюдь не легче, чем мегакнопку. Более того, если даже требование относительно прозрачное, понятное и логически допустимое, то практическая реализация может оказаться сложной совсем по другой причине. А именно по причине программиста А, упомянутого в начале.
Тут от программиста требуется еще один не всем очевидный для работодателя скил - скорость чтения чужого кода. Проще говоря большинство программистов на работе разбираются в коде других программистов. То есть на первый план выходит скорость, с которой программист читая чужой код понимает его.
Немного отвлекаясь в сторону надо отметить, что существует распространенное мнение, мол программирование это нечто крайне сложное, а языки программирования делятся на простые и для крутых. Причем положено считать, что чем круче программист, тем сложнее разобраться в его коде. Это в корне не так. Код крутого программиста должен быть способен читать любой новичок, и наоборот - код новичка сложнее читать крутому. Больше скажу - языки программирования и придумывают для того, что бы их было как можно проще читать всем, а не наоборот. Иначе бы все программисты писали на ассемблере. Который тоже в общем-то язык программирования, сделанный для упрощения.
Но это к слову. Как говорится, накипело. Есть реальная доля программистов считающих, что чем их код замысловатее и чем менее очевиден он для остальных, тем он, программист, круче. Из-за таких, с позволения, товарищей, чтение кода часто оказывается сложнее чем его полная переделка. Та одна десятая часть новых задач, возникает по большому счету из-за того что предыдущую программу проще и дешевле выбросить и написать заново.
Оценивать скорость, с которой программист читает, дело еще более неблагодарное, чем оценка того насколько быстро он учится новому. Эта скорость напрямую зависит от опыта. Как правило, чем больше программист читал чужого и разнообразного кода, тем он легче видит в нем логику. Возникает эдакая интуиция, когда читается мысль автора, а не конкретные инструкции. Программист читает программу, как бы, между строк, как хорошую художественную литературу.
Работодателю здесь следует обратить внимание на то, что скорость чтения совсем не показатель того, что сам программист хорошо умеет программировать. Можно сколь угодно много читать и цитировать классиков литературы, и при этом не очень здорово изъясняться письменно. Естественно, совсем безграмотно опытный программист не напишет, но и ожидать от человека наизусть помнящего всего Пушкина второго Евгения Онегина не следует.
Не работает это и в обратную сторону. То что у человека не хватает опыта быстро разобраться в старинной программе совсем не значит, что он сам не может написать нечто подобное и даже чуть лучше. Доверять всегда читать сложный код опытному программисту, а новичку постоянно давать чего полегче или с нуля плохая идея в долгосрочной перспективе. А лучше всего ставить их парами, что бы работали совместно.
Общая скорость
Работа в парах, в командах довольно таки распространенное нынче явление в программировании. Это либо ментор и джун, либо несколько разноплановых товарищей на одном проекте. В крупных компаниях можно встретить команды из пар. Вместе с тем, такой подход могут позволить себе далеко не все организации. Например, если в штате программиста два. Так же такой подход дороже обходится - затраты если не удваиваются, то заметно увеличиваются. Не даром было сказано: "Один программист делает за месяц то, что два программиста делают за два". Однако не все так однозначно.
Во-первых, опять же в долгосрочной перспективе лучше иметь два взаимозаменяемых кадра, чем два отдельных специалиста. Во-вторых, немаловажен фактор качества при перекрестной проверке кода. Итоговый исходник будет будет всегда проверен дважды. В-третьих, при работе в паре или в команде, программист вынужденно пишет код сразу понятно и читаемо для другого. Ну и в-четвертых, проще оценить производительность труда команды чем каждого в отдельности.
Не зря в примере с каменщиками я взял расчет на бригаду, а не на отдельного каменщика. В бригаде кто-то больше таскает воды, кто-то больше замешивает раствор, кто-то ловчее всех кладет. Даже если в бригаде двое, то они могут сменять друг друга, и таким образом меньше уставать. А главное - их работа будет в среднем значительно стабильнее по количеству. Программисты тоже такие же люди и могут достаточно хорошо распределять обязанности, оптимизировать работу и организовываться без внешнего участия.
Да, существует проблема того, что в программировании процесс нельзя так четко разделить по частям и распараллелить. Программисты часто могут попадать в противоречивые ситуации, ждать друг друга. Но в общем и целом ожидаемая производительность труда будет более предсказуема. Да, пусть одну задачу вдвоем два месяца, вместо двух задач за месяц по отдельности, но зато точно не застрянут на четыре.
Индивидуальная скорость
Так, а как же тогда, собственно, скорость набора кода десятипальцевым методом? - спросит читатель. Безусловно, существует и такой параметр. Какой-то индивид банально быстрее печатает. Кто-то очень ловко умеет пользоваться готовыми инструментами. Есть неутомимые люди с неимоверной усидчивостью и настырностью. Одни много думают, и делают мало, но сразу правильно. Другие способны настрочить килобайты кода, а на следующий день все выбросить и переписать заново. Опытные, новички, быдлокодеры, перфекционисты, тормоза от природы, гении от нее же... всего не счесть.
Однако ничего из этого не особенно влияет на суммарную производительность. Вернее сказать влияет все вместе. Гений архитектор баз данных может тупить и тормозить на пользовательских интерфейсах. Турбокодер может оказаться не способным сразу понять что от него требуется. Кто-то может загораться и устраивать марафоны, а потом столько же времени находиться в прострации. В сумме получается не очень то и разнообразно. Конечно, в итоге один работает в бухгалтерии строительно-монтажного управления, а другой разрабатывает программы для квантовых компьютеров, но это как и везде.
Взять одного среднего программиста и оценить его производительность на длинной дистанции сложно, да и незачем. Важнее учесть все вышесказанное, и многие другие обстоятельства, и корректно подойти к оценке в каждой отдельно взятой ситуации. Так можно и выжать нужную скорость из программиста, и выбрать соответствующее вознаграждение.
А программистам советую не заморачиваться на какой-то отдельной скорости, а стремиться к тому что бы развивать каждую из скоростей в равной степени, и в итоге лучше ориентироваться в средней.
*/
End;