Я, где-то с 2005 года, с перерывами, работаю в компаниях, которые решают задачи за деньги. Ну это когда клиент приходит, просит чего-то ему запрограммировать, мы делаем, и он нам платит. Там есть и проекты, но в тексте – только про разовые задачи. Да, это про 1С. Не про какую-то конкретную компанию – проблема одна для всех, нигде ее не решили нормально.
Так вот, самая скользкая тема в нашей работе – оценка трудоемкости задач. И гадость в том, что, какую бы оценку мы не давали, она будет казаться нечестной.
Вся гадость кроется в сути работы программиста 1С на небольших задачах по доработке. Если вы не в курсе, я кратко поясню.
Задачу, обычно, надо решить в какой-то конфигурации 1С. Это большая программа, написанная или фирмой 1С, или каким-то из ее партнеров. Клиенту надо изменить поведение какого-то механизма – или чутка, или нормально так, или совсем. А бывает, что заранее не известно, надо ли менять программный код или структуру данных – возможно, задачу можно решить средствами настройки, уже заложенными в конфигурации.
Вот в этом «возможно» и зарыта собака. Можно исходить из аксиомы, что всех способов решения задачи не знает никто, даже разработчик конфигурации – просто потому, что некоторые задачи решаются организационно, вне контекста ПО.
Один программист знает один способ, другой – два способа, третий – четыре, и т.д. Лютый программист не знает ни одного способа, но уверен, что, если покопаться, найдет десять.
Один способ – одна строка кода, второй – десять, третий – проект на полмиллиона, четвертый – организационные изменения бизнеса заказчика, покупка нового сервера, консалтинговый проект. И т.д.
Поэтому вариативность в решении задач очень высокая, начиная с направления решения, заканчивая использованием типовых (написанных фирмой 1С) стандартных подсистем vs написания кучи собственного говнокода.
Вернемся к теме. Допустим, есть некая задача. Пусть это будет выгрузка данных из базы 1С в формате JSON по списку, перечисленному заказчиком (контрагенты, отгрузки, долги и т.д.) – каждый кусок в своём формате, с разным уровнем вложенности и т.д.
Обычно происходит так – задачу дают на оценку предполагаемому исполнителю, или некоему эксперту, или обоим сразу, для верности. Допустим, получается 8 часов. Оценка согласовывается с клиентом, и специалист приступает к работе.
Зная оценку, приличный специалист стремится решить задачу быстрее, чем за 8 часов. Допустим, у него получилось за 6. Нечестно? Ну да.
Мы специалиста ругаем, говорим, что он не прав, завысив изначальную оценку, и надо было сразу ставить 6 часов. И в следующий раз чтоб ни-ни!
Специалист обижается, и в следующий раз тупо отказывается делать работу с этим клиентом или менеджером, ссылаясь на занятость. Задача уходит, допустим, стажеру, с оценкой в 6 часов.
А стажер, к сожалению, не знает, что такое JSON. И что такое выгрузка представляет себе слабо. Не говоря уж о метаданных конфигурации, из которой надо получить данные. И отборы никогда не видел. А данные умеет только в эксель выгружать, мышкой. В итоге, просидит с задачей все 32 часа. А клиент заплатит за 6. Опять нечестно! Только на этот раз мы угорели, а не клиент.
Ок, плюем на предварительные оценки. Пусть специалист просто решает задачу, а часы, выставляемые клиенту, возьмем по факту. Честно же? Увы, ни хрена.
Стажер просидит те же 32 часа. Если выставить такую сумму клиенту, он будет писать кипятком и орать, что это нечестно.
А если просидит толковый специалист, сколько часов получится? Скорее всего, 8, потому что столько, по его мнению, и стоит эта задача. А может, и все 12 – он ведь знает, сколько с задачей просидел бы стажер. Опять нечестно.
А через некоторое время приличный специалист начнет возмущаться, что его квалификация, умение планировать свое время, колоссальный опыт и знания пропадают даром. Какой отныне смысл стараться, если получишь столько, сколько просидел? Сама суть, цель его работы меняется – надо не сделать хорошо и быстро, а лишь подольше ПРОСИДЕТЬ. Но просидеть дольше, чем рабочий день, сложно. Нафиг идут личная жизнь, семья, выходные – специалист будет сидеть по 12 часов, потому что это время ему оплачивается.
Клиент, узнав об этом, скажет – нечестно! Особенно, если увидит фотографию рабочего дня.
А бизнесу каково? Любой бизнес ведь только и думает, что об эффективности. Эффективность, я напомню – это отношение полученного результата к приложенным усилиям. Когда результат – это решенная задача, то появляется поле для снижения объема приложенных усилий. А когда результат – это потраченное время (ведь именно оно продается), то получается, извините, бордель с почасовой оплатой. Единственный способ роста доходности борделя – увеличение масштаба, т.е. точек зарабатывания денег. Увеличение штата, короче говоря.
Знатоки борделей скажут – фигня. Можно повышать квалификацию, и продавать специалистов по разной стоимости часа. Прекрасная идея! Пусть час работы специалиста для клиента стоит впятеро дороже, чем час работы стажера!
Звучит заманчиво, но для клиента-то ничего не изменится. Специалист делает за 6 часов, стажер – за 32. Сумма к оплате получается одинаковая. Уже не нечестно, конечно, а просто никак.
Но может быть и нечестно, специалисты ведь не равны. Если два человека имеют опыт по 10 лет, они всё равно будут решать задачи с разной скоростью и трудоемкостью. Причем, разница может быть в 2-3 раза.
Можно начать извращаться, определяя ставку специалиста не исходя из его квалификации, а исходя из его способности решить конкретную задачу. Например, программист со стажем 10 лет будет решать задачу по расчету зарплаты дольше, чем консультант по расчету зарплаты со стажем 2 года. Получается, нужна динамическая (очень динамическая!) корректировка стоимости часа, исходя из задачи. Для ее вычисления придется нанять пару толковых диспетчеров.
Есть совсем извращенные способы, вроде определения стоимости работ по альтернативным издержкам. Например, чтобы клиенту работать с внешними подрядчиками было выгоднее, чем с собственными специалистами. Если сравнить чисто стоимость часа, то внутренний фикси – выгоднее. Если же объем работ в целом не такой большой, чтобы загрузить человека на 100 %, то аутсорс – выгоднее. При таком способе расчеты также будут сложными, контекстно-зависимыми и динамическими. И нечестными, т.к. будут сравниваться понятия, которые сравнить сложно – цена конкретной работы и неспособность к грамотному управлению внутренними сотрудниками.
Да и клиенты все разные, и никакой способ оценки не будет одинаково честным или нечестным для всех. Один считает каждую копейку, и готов часами сидеть с секундомером над душой у программиста, и обязательно на территории работодателя, чтобы его не накололи. Другой вообще не приемлет никакой почасовки, фактической оценки и вероятностей. Ему нужна конкретная стоимость и четкий срок, которые он согласует с руководством, внесет в бюджет, пройдет сложную процедуру утверждения заявки на расход денег, а сколько уж уйдет по факту — его вообще не колышет.
Цена, которую клиент готов заплатить за конкретную работу, очень сильно зависит от контекста, условий конкретного момента. Например, от того, насколько клиенту больно, пока задача не решена. Если в розничном магазине алкоголя легла касса и ЕГАИС, то клиенту очень больно. Если бухгалтер хочет кнопочку, которая заполнит два поля в документе, которые он успешно заполнял руками, то не больно совсем.
Если у вас болит зуб – так, что не помогают никакие обезболивающие, невозможно ни есть, ни пить, ни спать, ни работать, то вы побежите в первую попавшуюся стоматологию, чтобы снять боль. Если же вы хотите сделать гигиену полости рта, то вполне подождете и пару месяцев, тщательно выбирая клинику, специалиста и поджидая какой-нибудь акции. И то, и другое будет вам казаться честным, несмотря на серьезную разницу в цене.
Так что, какую бы оценку не получила задача, честности в ней не будет. Абсолютной, идеальной, белой и пушистой честности, про которую пишут в детских книгах. Тут нет черного и белого, есть только оттенки серого.
Лично мне больше нравится предварительная оценка, потому что она дает не только возможность, но и мотивацию к повышению собственной эффективности. Оценка по факту – напротив, убивает стремление к эффективности напрочь, превращая человека в «каменную задницу» (так называли Молотова), желающую лишь подольше просидеть.
Предварительная оценка – отличный стимул для роста стажера. Если он знает цену работы заранее, и видит, что просидел в пять раз дольше, то объективно понимает свою тупость. А видя другого специалиста, который, хотя бы, уложился в оценку, стремится стать таким же.
Для клиента, если разобраться, честной может быть только одна цена – ноль. Частенько она сопровождается аргументацией «я и так купил вашу программу, почему я должен еще за что-то платить?».
Но на деле, мне кажется, критерий честности для клиента один: он готов заплатить указанную цену. Если не готов, надо торговаться, как за башмаки на рынке. Граница снижения определяется, как в любом бизнесе, финансовыми и политическими целями и показателями обеих сторон.
А как оценивать работы? Мне близка оценка по Джону Доу (так в США называют неизвестного подозреваемого). Джон Доу – это некий средний программист. Круче, чем стажеры, но хуже, чем опытные специалисты. Некий средний.
Стажеры должны стремиться стать Джоном Доу, что в цифрах означает, например, конверсию, равную 1, при отсутствии потерь между задачами и входящем потоке работы, обеспечивающем стопроцентную загрузку. Такого потока обычно нет, поэтому можно снизить планку – пусть Джон Доу делает в день по 6 часов. В месяц получится примерно 126 часов. Ни много, ни мало. Джон Доу. Напомню, речь о небольших задачах, а не проектной загрузке.
Толковый специалист, догнав и перегнав Джону Доу, может зарабатывать намного выше среднего. Его квалификация, компетенции, умение быстро вникать, писать код, как Бог, своевременное изучение новых механизмов и инструментов, проактивная работа с клиентами, грамотно политически выстроенная работа с менеджерами, четкое соблюдение сроков – всё то, что делает его толковым специалистом – наконец, начнет приносить ему доход.
Иначе какой смысл становиться толковым специалистом, при одинаковой для всех часовой ставке? Или при оценке работ по факту? Инвестиции в себя должны окупаться, иначе нет смысла их делать.
Как оценивать по Джону Доу? Сразу скажу – не знаю. Это приходит с опытом. Спросите какого-нибудь опытного специалиста, как он оценивает работы. Просто смотрит на задачу, и называет оценку. Всё. Нет никакого алгоритма, есть опыт, представление о стоимости работ, накопленная внутренняя статистика.
Голова просто выдает ответ на вопрос «сколько такую работу будет делать средний специалист».
С одной стороны, это мистика. С другой, я несколько раз в жизни проверял, и каждый раз убеждался, что метод работает.
Например, мы независимо с разными специалистами, с опытом 8-15 лет, оценивали работы, и почти всегда получались предельно близкие цифры. Однажды, несколько лет назад, я оценивал большой перечень работ, который в сумме вышел на 2000 часов. Потом дал своему коллеге, чтобы тот оценил по-своему, не глядя на мой результат, и у него вышло 1990 часов. Магия, не иначе.
Оценка по Джону Доу, конечно, тоже не честная. Как и любая другая. Просто поймите, примите и используйте: честных оценок не бывает. Вообще.
Оценка – это инструмент, которым можно пользоваться, достигая разных целей.
Для менеджера оценка – это способ получить клиента. Или привязать клиента. Или переманить клиента. Или заработать денег. Или заработать больше денег. Или раскрутить клиента.
Для специалиста оценка – это цель, мотив для роста квалификации, причем – разносторонней. И программировать быстро, и вникать в незнакомые конфигурации и механизмы, и общаться с клиентом, и спрашивать помощи, и получать ее, и использовать чужие решения.
Для компании оценка – это инструмент управления. Понятный, прозрачный, элемент системы мотивации. Он позволяет управлять, не управляя.
Краткое содержание
Честной оценки стоимости решения задачи не бывает.
Любая оценка зависит от контекста.
Контекст включает специалиста, который решает задачу, менеджера, который ее продает, клиента, который за нее платит, конкретного представителя клиента, который должен оценку согласовывать, и т.д.
Предварительная оценка может быть ошибочной, т.к. в нее заложены риски.
Оценка по факту может быть ошибочной, т.к. не известно, с какой скоростью движется исполнитель — реальной или «чтоб подольше просидеть».
Нормирование — вообще невозможно.
Наиболее перспективной кажется оценка по Джону Доу — сколько эту задачу решал бы средний программист.
Получается всё-таки предварительная оценка, но не по конкретному специалисту, а по вымышленному среднему.
Стажеру есть куда стремиться — он работает хуже, чем Джон Доу.
Опытному есть куда стремиться — он работает лучше, чем Джон Доу.
Когда оценка известна заранее, есть и цель, и мотив к повышению эффективности и ее применению.
