Не редки случаи, когда ставший начальником или руководителем проекта бывший программист позволяет себе высказывания "Ну почему вы все так долго делаете? Я сам бывший программист и знаю, что там и делать-то нечего!" В более тяжелых случаях такой товарищ добавляет еще что-то вроде "А вот я бы..."
Сложно сказать, насколько эти случаи распространены. К сожалению, я и сам попался на эту удочку. Хотя честно пытался бороться с этим эффектом и старался себя сдерживать, но не всегда это удавалось :(
Тем интереснее, после руководящей работы, вновь почувствовать себя в шкуре программиста и ощутить на себе трудоемкость этого трудно прогнозируемого занятия. На личном, так сказать, примере.
В течении последней недели я занимался реализацией синхронного взаимодействия агентов в SObjectizer. На рождение идеи ушло где-то два дня. И еще дня полтора на получение первой реализации. Казалось, что осталось всего-ничего: пару тестов, один-два примера и всех делов.
Однако сейчас, когда все это уже закончено, можно оглянуться назад и сказать, что в действительности эти "пара тестов и один-два примера" заняли намного больше, чем я ожидал. Как по времени, так и по усилиям.
Проиллюстрировать это можно в цифрах. Хотя LOC-и (т.е. количество строк кода) -- это параметр не очень адекватный, но в данном случае подойдет и он.
Итак, создание первой рабочей версии привело к увеличению количества строк в проекте на ~500 штук (с 16271 на ревизии 570 до 16744 на ревизии 573). Тут считаются только новые строки, еще какое-то их количество было переработано, а что-то и вовсе выброшено. Ну да не суть. Важно то, что в эти 500 строк уложились основные изменения, которые затем правились еще, но уже не кардинальным образом. Т.е., грубо говоря, ядро изменений, на придумывание которого ушло два дня, и еще день на реализацию -- это эти самые 500 строк кода.
А вот когда новый код был покрыт тестами и проиллюстрирован несколькими примерами, размер проекта увеличился еще на ~2000 строк (18977 на ревизии 597). И опять таки, для простоты считаются только новые строки, а те, которые перерабатывались и удалялись от ревизии к ревизии, не учитываются. Т.е. фактической работы было еще больше.
Промашка по срокам на создание всей этой тестовой и демонстрационной обвязки составила два раза: 4 дня вместо предполагавшихся мной 2.
При том, что когда неделю назад я брался за идею реализации синхронных сервисов, у меня вообще не было представления о том, как эта задача будет решена, сколько времени потребуется на поиск решения, и сколько потом еще нужно будет на реализацию и тестирование. Просто повезло, что идея возникла буквально внезапно, как вспышка: бах и все, вот она, на ладошке! :)))
И еще одно крайне немаловажное уточнение: над SObjectizer-ом я сейчас работаю просто в идеальных условиях: трачу на него столько времени, сколько нужно. Мои усилия ограничиваются только моими физическими возможностями. Это прекрасно известная мне предметная область и хорошо знакомый мне код. Я пользуюсь инструментами, которыми владею достаточно уверенно и про которые легко найти необходимую информацию в Интернете. Надо мной не давлеют сроки. Мне не нужно общаться с заказчиком и/или руководством. Меня не отвлекают работающие по соседству программисты или тестировщики, или внедренцы, или суппорт. Мне не нужно тратить время на дорогу в офис и обратно...
В общем, абсолютно точно могу сказать, что ни у одного ведущего разработчика, выполняющего важный кусок работы в офисе, практически не будет таких тепличных условий для полной концентрации над своей задачей. Посему если я сейчас промахнулся с оценкой сроков тестирования в два раза, то работая в офисе эта ошибка легко составила бы 3-4, а то и более раз.
Подчеркну, что здесь даже и речи не идет о том, что рабочее время может тратиться на какие-то непроизводственные вещи, вроде хождения на офисную кухню за чаем или случайные разговоры за жизнь. Просто в офисе к твоим производственным обязанностям относится еще столько мелочей, которые незаметно отнимают массу времени, что просто невероятно...
К сожалению, чем дальше ты уходишь от разработки в начальствование, тем меньше ты об этом помнишь. Отсюда и неправильное мнение о том, с какой скорость должна идти работа. Хотя, казалось бы, всего год-полтора назад ты об этом прекрасно помнил! :)
Ну а под занавес, дабы два раза не вставать, добавлю еще несколько слов про ценность программиста. ЕМНИП, я неоднократно писал у себя в блоге, а еще чаще устно говорил руководителям разных рангов, что одна из тяжелейших потерь, связанных с уходом разработчика -- это потеря тех идей, которые были у него в голове. Большинство этих идей никогда и нигде формально не фиксируется! Но, даже если фиксируется, то не разжевывается до таких подробностей, чтобы любой другой программист взял и воплотил их в коде. В лучшем случае остаются следы этих идей от кулуарных разговоров и споров в памяти их участников (если они сами продолжают работать в компании).
В качестве демонстрации приведу пример из той же реализации синхронных сервисов в SObjectizer. Дабы не забывать что еще нужно сделать, я завел в Wiki простой TODO-лист, который начался всего с нескольких строк, имеющих отношение к синхронным сервисам (вот этот вариант). Но затем он трансформировался во все более и более подробный перечень разных вкусностей и полезностей (в том числе и крайне спорных). Вот, к примеру, один из промежуточных вариантов. И это при том, что я далеко не сразу фиксирую там то, что приходит в голову. Какие-то вещи требуют "вызревания" для формализации. Какие-то требуют борьбы с собственной ленью :) А ведь далеко не все разработчики имеют привычку вот такой фиксации своих идей. Особенно, если речь идет не о собственном проекте, а о том, чем ты занимаешься на работе "для дяди"...
Так что, дорогие начальнички, если вы хотите успешного выполнения проектов, то берегите своих разработчиков (а так же тестировщиков, технических писателей, внедренцев, саппортеров, дизайнеров и т.д.). Без вас проекты будут выполняться, уж можете мне поверить. А вот без них...
Сложно сказать, насколько эти случаи распространены. К сожалению, я и сам попался на эту удочку. Хотя честно пытался бороться с этим эффектом и старался себя сдерживать, но не всегда это удавалось :(
Тем интереснее, после руководящей работы, вновь почувствовать себя в шкуре программиста и ощутить на себе трудоемкость этого трудно прогнозируемого занятия. На личном, так сказать, примере.
В течении последней недели я занимался реализацией синхронного взаимодействия агентов в SObjectizer. На рождение идеи ушло где-то два дня. И еще дня полтора на получение первой реализации. Казалось, что осталось всего-ничего: пару тестов, один-два примера и всех делов.
Однако сейчас, когда все это уже закончено, можно оглянуться назад и сказать, что в действительности эти "пара тестов и один-два примера" заняли намного больше, чем я ожидал. Как по времени, так и по усилиям.
Проиллюстрировать это можно в цифрах. Хотя LOC-и (т.е. количество строк кода) -- это параметр не очень адекватный, но в данном случае подойдет и он.
Итак, создание первой рабочей версии привело к увеличению количества строк в проекте на ~500 штук (с 16271 на ревизии 570 до 16744 на ревизии 573). Тут считаются только новые строки, еще какое-то их количество было переработано, а что-то и вовсе выброшено. Ну да не суть. Важно то, что в эти 500 строк уложились основные изменения, которые затем правились еще, но уже не кардинальным образом. Т.е., грубо говоря, ядро изменений, на придумывание которого ушло два дня, и еще день на реализацию -- это эти самые 500 строк кода.
А вот когда новый код был покрыт тестами и проиллюстрирован несколькими примерами, размер проекта увеличился еще на ~2000 строк (18977 на ревизии 597). И опять таки, для простоты считаются только новые строки, а те, которые перерабатывались и удалялись от ревизии к ревизии, не учитываются. Т.е. фактической работы было еще больше.
Промашка по срокам на создание всей этой тестовой и демонстрационной обвязки составила два раза: 4 дня вместо предполагавшихся мной 2.
При том, что когда неделю назад я брался за идею реализации синхронных сервисов, у меня вообще не было представления о том, как эта задача будет решена, сколько времени потребуется на поиск решения, и сколько потом еще нужно будет на реализацию и тестирование. Просто повезло, что идея возникла буквально внезапно, как вспышка: бах и все, вот она, на ладошке! :)))
И еще одно крайне немаловажное уточнение: над SObjectizer-ом я сейчас работаю просто в идеальных условиях: трачу на него столько времени, сколько нужно. Мои усилия ограничиваются только моими физическими возможностями. Это прекрасно известная мне предметная область и хорошо знакомый мне код. Я пользуюсь инструментами, которыми владею достаточно уверенно и про которые легко найти необходимую информацию в Интернете. Надо мной не давлеют сроки. Мне не нужно общаться с заказчиком и/или руководством. Меня не отвлекают работающие по соседству программисты или тестировщики, или внедренцы, или суппорт. Мне не нужно тратить время на дорогу в офис и обратно...
В общем, абсолютно точно могу сказать, что ни у одного ведущего разработчика, выполняющего важный кусок работы в офисе, практически не будет таких тепличных условий для полной концентрации над своей задачей. Посему если я сейчас промахнулся с оценкой сроков тестирования в два раза, то работая в офисе эта ошибка легко составила бы 3-4, а то и более раз.
Подчеркну, что здесь даже и речи не идет о том, что рабочее время может тратиться на какие-то непроизводственные вещи, вроде хождения на офисную кухню за чаем или случайные разговоры за жизнь. Просто в офисе к твоим производственным обязанностям относится еще столько мелочей, которые незаметно отнимают массу времени, что просто невероятно...
К сожалению, чем дальше ты уходишь от разработки в начальствование, тем меньше ты об этом помнишь. Отсюда и неправильное мнение о том, с какой скорость должна идти работа. Хотя, казалось бы, всего год-полтора назад ты об этом прекрасно помнил! :)
Ну а под занавес, дабы два раза не вставать, добавлю еще несколько слов про ценность программиста. ЕМНИП, я неоднократно писал у себя в блоге, а еще чаще устно говорил руководителям разных рангов, что одна из тяжелейших потерь, связанных с уходом разработчика -- это потеря тех идей, которые были у него в голове. Большинство этих идей никогда и нигде формально не фиксируется! Но, даже если фиксируется, то не разжевывается до таких подробностей, чтобы любой другой программист взял и воплотил их в коде. В лучшем случае остаются следы этих идей от кулуарных разговоров и споров в памяти их участников (если они сами продолжают работать в компании).
В качестве демонстрации приведу пример из той же реализации синхронных сервисов в SObjectizer. Дабы не забывать что еще нужно сделать, я завел в Wiki простой TODO-лист, который начался всего с нескольких строк, имеющих отношение к синхронным сервисам (вот этот вариант). Но затем он трансформировался во все более и более подробный перечень разных вкусностей и полезностей (в том числе и крайне спорных). Вот, к примеру, один из промежуточных вариантов. И это при том, что я далеко не сразу фиксирую там то, что приходит в голову. Какие-то вещи требуют "вызревания" для формализации. Какие-то требуют борьбы с собственной ленью :) А ведь далеко не все разработчики имеют привычку вот такой фиксации своих идей. Особенно, если речь идет не о собственном проекте, а о том, чем ты занимаешься на работе "для дяди"...
Так что, дорогие начальнички, если вы хотите успешного выполнения проектов, то берегите своих разработчиков (а так же тестировщиков, технических писателей, внедренцев, саппортеров, дизайнеров и т.д.). Без вас проекты будут выполняться, уж можете мне поверить. А вот без них...
Комментариев нет:
Отправить комментарий