Для начала возьмем такую четкую, формализованную цепочку:
- Программист, пишет код и ничего его больше не интересует.
- Тестировщик берет код у программиста и тестирует его, в случае ошибок, возвращает код на исправление.
- Менеджер по продажам берет у тестера готовый дистрибутив и продает его клиенту.
- Клиент использует программу, и в случае проблем с программой обращается в службу технической поддержки.
- Техническая поддержка работает только с клиентом, отвечает на его вопросы, и плевать им на остальные отделы. Пожелания отправляет программистам.
Пока так, без усложнений. Все занимаются своим основным делом, и не общаются друг с другом через отдел, например, менеджер по продажам с программистами не общается, а только с клиентами. Цепочка однонаправленная. Посчитаем, что получается. Пусть средний программист НЕ допускает ошибку с вероятностью 0,5. Обычный средний тестировщик найдет эту ошибку с вероятностью 0,5. Менеджер сможет продать клиенту программу с вероятностью 0,5 (хотя, наверное, это очень высокая вероятность). В итоге у клиента окажется на руках наша «глюкавая» программа с нашей искомой ошибкой с вероятностью 0,5*0,5*0,5=0,125. Клиент может НЕ наткнуться на ошибку в программе в среднем, ну пусть, тоже с вероятностью 0,5. И, соответственно, техническая поддержка поможет клиенту пофиксить ошибку с вероятностью 0,5. Тогда вопрос с первоначально возникшей ошибкой у первого звена (программиста) будет решен с вероятностью 0,125*0,5*0,5=0,03125. Не придирайтесь к цифрам- они нужны как начальная точка для рассуждений. Вот эта вероятность 0,03125- она является мерой того, насколько клиент будет раздражен нашей ошибкой. Здесь 0- клиент в бешенстве, 1- клиент абсолютно доволен. Соответственно, если клиент раздражен, он всем скажет, что программа плохая, никто ее не купит больше и т.д. В общем, 0,03125- это мера успешности компании. Т.е. это то, к чему мы стремимся- успешности компании через производство качественного, радующего покупателей программного продукта. Получается, что, если полученный коэффициент равен 1, то компания успешна, если 0- неуспешна.
Возьмем теперь две крайности. На работу взяли тупого программиста, который не допустит ошибки в программе с вероятностью 0,1. Получается, что вероятность успешности компании, при всех остальных неизменных параметрах равна 0,1*0,5*0,5*0,5*0,5=0,00625.
Другая крайность- талантливый программист с вероятностью недопускания ошибки 0,9. Получается 0,05625. Разница между тупым и талантливым- 11% составила. С одной стороны здорово, но с другой стороны максимум успешности равен 1. А мы за счет таланта программиста добавили в копилку успешности только (0,05625-0,00625)=0,05 единиц, т.е. 5%.
Вы уже сообразили, к чему я клоню? «Догнать» уровень успешности до значений, близких к максимумам, можно, улучшив работу тестировщиков, менеджеров по продажам, технической поддержки. И в совокупности, это позволит нам достичь 0,99 единиц успешности. 0,01- это клиенту «на погоны», ведь он тоже в цепочку включен. В данной формуле успешность определяется самым слабым звеном. Возьмите лучших тестеров, менеджеров, саппорт- по 1 единице вероятности им дайте. Но если будет тупой программист с его 0,1 единицами, то в итоге успешность компании не превысит 0,1.
Какие выводы можно сделать? Компания для повышения вероятности своей успешности должна набирать в штат не только талантливых программистов, но и остальной персонал должен блистать талантами. Только так.
Тривиальный вывод, правда? И как это может помочь нам, программистам, и вообще ITшникам? Первое, что напрашивается, и без этих расчетов- это при трудоустройстве оценивать как с вами кадровики общаются. Ведь в успешной компании все должно быть на высоком уровне. И если вам с порога хамит охранник, игнорирует кадровик, решая свои вопросы и т.д., то наверняка в компании что-то не так. Цепочка бизнес-процессов где-то дает слабину, а, значит, уменьшает вероятность того, что компания окажется успешной.
Однако жизнь куда как заковыристей, чем описанная выше формализованная модель. Программисты знают не один адрес сайта с черными списками работодателей. При этом предприятия из этих списков не разоряются, а очень неплохо себя чувствуют, хотя точно хороших программистов им к себе не заманить. Так как же выживают такие предприятия? Ведь, согласно представленной выше модели, звено «программист» на таком «черносписочном» предприятии получит коэффициент ближе к нулю, а значит и успешность предприятия будет низкая.
Данная модель будет описывать подобные случаи, если ввести коэффициенты значимости для каждого звена. Предлагаю такой вариант формулы: (x+k)/2, где x- вышеописываемые вероятности допускания соответствующими отделами ошибок, k- коэффициент значимости работы отдела для получения конечного результата, т.е. для повышения вероятности успешности компании. Пусть значимость отдела программистов оценивается в 0,5. Тогда, если брать тупых программистов (вероятность НЕ допускания ими ошибки равна 0,1), то значимость качественной работы программистов на конечный результат составит (0,1+0,5)/2=0,3. Соответственно, для талантливых программистов (0,9 вероятность) получаем (0,9+0,5)/2=0,7. Выводы: если работа отдела не сильно сказывается на конечном результате, то таланты не смогут внести существенного вклада в проект, и, соответственно, тупицы тоже особо ничего не испортят. Вот сравните: разница между тупыми и талантами составляет 0,9/0,1=9 раз, а на конечном результате разница видна всего в 0,7/0,3=2,3 раза. Такая ситуация реальна, и часто встречается в «карманных» конторах или предприятиях, стоящих у какой-либо крупной «кормушки». Для таких предприятий важнее не талант программиста, а хорошие менеджеры со связями. Часто внутри таких предприятий атмосфера стоит склочная, начальство прислушивается к менеджерами (ведь они кормильцы предприятия, получается), а те все свои ошибки визгливо валят на программистов, тех в очередной раз называют бездельниками и закручивают гайки (Интернет отбирают, контролируют опоздания и уходы с работы и т.п.).
Итоговая формула получается такая:
,Где K- вероятность успешности предприятия; i- кол-во отделов, плюс заказчик; k- вероятность безошибочной работы соответствующего отдела; a- коэффициент значимости отдела для компании или, по-другому, насколько вероятно то, что ошибка, допущенная отделом, скажется на конечном результате. Если у нас 5 отделов (см. рисунок 1), то вместе с заказчиком у нас получается 10 переменных с формуле. И только одна переменная, вероятность НЕ допускания ошибки программистом, напрямую зависит от программиста, от его таланта. И чем крупнее предприятие, тем менее заметно влияние таланта программиста на конечный результат компании. Даже в такой простой вышеприведенной схеме талант программиста уже незначителен для конечного результата: предприятие может быть успешным с довольно высокой вероятностью и без талантов, опираясь на «середнячков». Ясно, что любой здравый руководитель предпочтет нанять середнячка и платить ему меньше, чем нанять дорогущего таланта и, практически, не видеть его вклада в конечный продукт (прирост вероятности успешности предприятия будет совсем небольшим, не оправдывающим денег, вложенных в талант).
Теперь можно делать более глобальные выводы, кроме того, что кадровики должны быть с вами обходительны:
- Чем крупнее компания, тем меньшую значимость для компании будет иметь каждый талантливый программист в отдельности. Для компании, практически с тем же результатом, дешевле будет нанять середнячков, чем талантов. Любой талант в такой компании будет со временем «причесан» под общую гребенку- его способности не будут востребованы и он отупеет до общего уровня.
- В маленьких компаниях отделов меньше, людей меньше, поэтому важность каждого человека высока. Компания заинтересована нанять таланта и удерживать его всевозможными бонусами.
- «Карманные» и «прикормленные» компании равнодушны к талантам- там их труд практически не сказывается на конечном результате.
Итог: Идеальная компания для программиста- небольшая, с отличными специалистами во всех отделах (вплоть до уборщицы), дружелюбными, профессиональными.
Что же получается тогда? Какая бы ни была компания внешне дружественная к программистам, активно зазывающая к себе, создающая блага, но если компания большая, то предложенная формула приводит нас к печальному выводу: «Талантливому программисту там делать нечего». И, наоборот, внешне непривлекательная небольшая компания может стать настоящей отдушиной для таланта, где он может раскрыться по максимуму.
Остается упомянуть о еще нескольких моментах. Первое, умные большие компании, ощутив на себе «смертельное дыхание» данной формулы, формируют из предприятия холдинг, состоящий из маленьких предприятий, ведущих самостоятельную деятельность. Это неплохо, но часто из управляющей компании холдинга прямо таки веет тупизной, бюрократизмом и предприятия холдинга ощущают это на себе. Периодические набеги руководства холдинга не дают расслабиться, и талантам там все же несколько неуютно. И второй момент, я не учитывал в формуле наличие босса, через которого формируются более сложные связи между отделами.
Оценивая формулу, я вижу, что на ее основе можно развить методологию оценки эффективности деятельности предприятия, притом основанную на количественных показателях деятельности организации. Хммм, вплоть до того, что можно осуществить мечту любого начальника: на экране компьютера кривая, которая в реальном времени показывается эффективность предприятия.
Однако, пора уж закругляться, а то так и до планирования мировой экономики договориться можно!
