Здравствуйте, SkyKnight, Вы писали:
SK>Здравствуйте, gandjustas, Вы писали:
G>>Видимо выделенное и было причиной что код не читал. G>>Я большую при приемке первое что делаю — читаю код. Это же обычно и последнее.
SK>Если бы я читал весь код, который нам делают подрядчики, я бы уже давно бы помер. SK>Просто так скажу, что у нас Warehousing система и для нее есть несколько плагинов, которые делают сторонние фирмы. Так вот, эти плагины на столько гигантские, что прочитать код даже теоритически нереально в короткое время. SK>Поэтому у меня есть просто несколько наборов тестовых данных, на которых я проверяю очередную версию плагина. Как оно там внутри устроено мне, в прицнипе, даже не интересно. Мне главное, чтобы плагины подрядчика работали, работали быстро и не валились от каждого движения мышкой. Если на своих тестовых наборах я воспроизвожу какой-то баг, то сообщаю об этом подрядчику и даю так же этот набор, чтобы он мог баг воспроизвести и пофиксить.
Ничего бы с тобой не стало. Средний программист пишет код примерно в 4 раза медленнее, чем средний же программист его читает.
То есть ты бы мог читать код 4-х человек и еще оставалось бы время покодить, подрядчики ведь не по 8 часов пишут.
Очень помогают тулы, особенно на начальном этапе, пока они считают что можно гнать фуфло.
Со временем подрядчики понимают как надо писать и начинают делать быстрее и лучше, тебе придется меньше времени читать их код.
Но ты как раз подтердил мои слова — приемка требует чтения кода, если ты не читаешь код, то можно за эту работу посадить в два раза более дешевого тестера.
SK>Если что-то случается на стороне заказчика с этим плагином, то просто беру дамп данных заказчика и отправляю подрядчику.
SK>Да и то, тестирую не я лично сам, а отдаю нашим тестеровщикам. Они это делают куда как лучше меня, а мне еще надо распределить задачи между разработчиками, составить список фич, спланировать, так что время для разработки у меня у самого почти не остается. А тут еще мегабайты кода читать.... Так я совсем никогда домой не попаду.
А ты зачем нужен в этой схеме работы с подрядчиками? Сам не тестируешь, код не читаешь, что ты вообще в приемке делаешь? Только передаешь туда-сюда?
Здравствуйте, gandjustas, Вы писали:
G>Ничего бы с тобой не стало. Средний программист пишет код примерно в 4 раза медленнее, чем средний же программист его читает. G>То есть ты бы мог читать код 4-х человек и еще оставалось бы время покодить, подрядчики ведь не по 8 часов пишут. G>Очень помогают тулы, особенно на начальном этапе, пока они считают что можно гнать фуфло. G>Со временем подрядчики понимают как надо писать и начинают делать быстрее и лучше, тебе придется меньше времени читать их код.
Все равно не понимаю зачем эти лишние движняки. Есть спецификация. Данные на входе -> данные на выходе за определенное время. Как они это реализуют, на чем, мне, честно говоря, совершенно неинтересно.
А так я представляю как каждый заказчик просматривает код софта, который он покупает.
G>Но ты как раз подтердил мои слова — приемка требует чтения кода, если ты не читаешь код, то можно за эту работу посадить в два раза более дешевого тестера.
Тестировщики не совсем дешевле разработчика. Они примерно одинаково стоят. Ну есть это, конечно, не такой, который просто кнопочки тыкает. Ему надо составить тест план, проверять на различных данных и прочее. В общем это работа совсем не такая легкая как кажется.
G>А ты зачем нужен в этой схеме работы с подрядчиками? Сам не тестируешь, код не читаешь, что ты вообще в приемке делаешь? Только передаешь туда-сюда?
Подписываю документы и несу ответсвенность. Если что, то все шишки на меня. Тестировщиков и разработчиков эти шишки не коснутся.
Здравствуйте, SkyKnight, Вы писали:
SK>Здравствуйте, gandjustas, Вы писали:
G>>Ничего бы с тобой не стало. Средний программист пишет код примерно в 4 раза медленнее, чем средний же программист его читает. G>>То есть ты бы мог читать код 4-х человек и еще оставалось бы время покодить, подрядчики ведь не по 8 часов пишут. G>>Очень помогают тулы, особенно на начальном этапе, пока они считают что можно гнать фуфло. G>>Со временем подрядчики понимают как надо писать и начинают делать быстрее и лучше, тебе придется меньше времени читать их код. SK>Все равно не понимаю зачем эти лишние движняки. Есть спецификация. Данные на входе -> данные на выходе за определенное время. Как они это реализуют, на чем, мне, честно говоря, совершенно неинтересно.
Затем что основные затраты на софт идут на этапе эксплуатации, появляются баги и всякие мелочи, которые надо поправить, очень большую роль играет UX и надежность кода при изменении параметров среды.
Причем тестировать все это непозволительно долго.
За свою практику я не видел кода, для которого было бы достаточно удовлетворения только функциональной спецификации.
Да и банально review ловит больше ошибок, чем тестирование.
SK>А так я представляю как каждый заказчик просматривает код софта, который он покупает.
В заказной разработке нередко клиенты заказывают аудит вашего кода у ваших конкурентов.
G>>Но ты как раз подтердил мои слова — приемка требует чтения кода, если ты не читаешь код, то можно за эту работу посадить в два раза более дешевого тестера. SK>Тестировщики не совсем дешевле разработчика. Они примерно одинаково стоят. Ну есть это, конечно, не такой, который просто кнопочки тыкает. Ему надо составить тест план, проверять на различных данных и прочее. В общем это работа совсем не такая легкая как кажется.
Смысла нет держать тестеров, если они в среднем выходят дороже программистов.
G>>А ты зачем нужен в этой схеме работы с подрядчиками? Сам не тестируешь, код не читаешь, что ты вообще в приемке делаешь? Только передаешь туда-сюда? SK>Подписываю документы и несу ответсвенность. Если что, то все шишки на меня. Тестировщиков и разработчиков эти шишки не коснутся.
Ну то есть ты приемкой то и не занимаешься, просто передастом работаешь.
Фактически качество кода подрядчиков контролирует только тестер.
1/14/2014 10:25 AM, SkyKnight пишет:
> Все равно не понимаю зачем эти лишние движняки. Есть спецификация. > Данные на входе -> данные на выходе за определенное время. Как они это > реализуют, на чем, мне, честно говоря, совершенно неинтересно. > А так я представляю как каждый заказчик просматривает код софта, который > он покупает.
"Ну как ты понять не можешь" ((С) известно чье), а вдруг они тебя
обманывают в говнокод подсовывают.
Здравствуйте, gandjustas, Вы писали:
G>Затем что основные затраты на софт идут на этапе эксплуатации, появляются баги и всякие мелочи, которые надо поправить, очень большую роль играет UX и надежность кода при изменении параметров среды.
Вот в этом и заключается задача тестировщика все еще отловить на этапе приемки. Хороший тестировщик сможет это все отловить, а плохой и нафиг не нужен.
SK>>А так я представляю как каждый заказчик просматривает код софта, который он покупает. G>В заказной разработке нередко клиенты заказывают аудит вашего кода у ваших конкурентов.
Никогда с таким не встречался. Да и даже в заказной работе в договоре исполнитель подпишет так, чтобы код не отдавать.
G>Смысла нет держать тестеров, если они в среднем выходят дороже программистов.
Хорошие тестировщики стоят дорого, у меня есть примеры, где они получают 80-100 евро в час. Хоть и называются они консультантами или еще как-то, но на самом деле являются тестировщиками и не более того.
G>Ну то есть ты приемкой то и не занимаешься, просто передастом работаешь. G>Фактически качество кода подрядчиков контролирует только тестер.
ну оно конечно можно, чтобы все делал один человек. И код писал и тестировал работу подрядчиков и руководил проектом и еще там бухгалтерию вел и все в сроки успевал, только если и будет такой человек, то стоить он будет столько, что дешевле нанять все-таки 4х. Если кто-то думает, что руководитель проекта просто чай на работе гоняет, то он глубоко заблуждается. Поэтому еще раз повторюсь, времени у меня на чтение кода, к тому же чужого.
1/14/2014 10:36 AM, gandjustas пишет:
> Ну то есть ты приемкой то и не занимаешься, просто передастом работаешь.
Вообще-то в отличие от тебя SK выполняет свою работу и не пытается лезть
во все дырки, а вот тебе, вероятнее всего, просто нечем заняться.
Здравствуйте, Vzhyk, Вы писали:
V>1/14/2014 10:36 AM, gandjustas пишет:
>> Ну то есть ты приемкой то и не занимаешься, просто передастом работаешь. V>Вообще-то в отличие от тебя SK выполняет свою работу и не пытается лезть V>во все дырки, а вот тебе, вероятнее всего, просто нечем заняться.
Почему это тебя интересует? Ты хочешь об этом поговорить?
Здравствуйте, SkyKnight, Вы писали:
SK>Здравствуйте, gandjustas, Вы писали:
G>>Затем что основные затраты на софт идут на этапе эксплуатации, появляются баги и всякие мелочи, которые надо поправить, очень большую роль играет UX и надежность кода при изменении параметров среды. SK>Вот в этом и заключается задача тестировщика все еще отловить на этапе приемки. Хороший тестировщик сможет это все отловить, а плохой и нафиг не нужен.
Тестер физически не может отловить все. Более того эффективность тестирования не так высока, как принято считать. Ловит от силы 30% дефектов. Остается только надеятся что подрядчик сам отловит остальные 70%.
SK>>>А так я представляю как каждый заказчик просматривает код софта, который он покупает. G>>В заказной разработке нередко клиенты заказывают аудит вашего кода у ваших конкурентов. SK>Никогда с таким не встречался. Да и даже в заказной работе в договоре исполнитель подпишет так, чтобы код не отдавать.
Исполнитель с таким договором пойдет нафиг чаще всего. Только недалекий ИТ-менеджер пропустит такой договор.
Я всем клиентам рекомендую всегда оставлять имущественные права на весь код решений.
G>>Смысла нет держать тестеров, если они в среднем выходят дороже программистов. SK>Хорошие тестировщики стоят дорого, у меня есть примеры, где они получают 80-100 евро в час. Хоть и называются они консультантами или еще как-то, но на самом деле являются тестировщиками и не более того.
Консультантами вообще все подряд называются. Я вот видел как умный заказчик тупо вычеркивал работы тестировщиков по 80 евро в час из сметы, говорил что пусть кодеры тестят, они дешевле получались.
Все что ты рассказываешь рассчитано на лохов. Золотые тестеры и не передача кода у любого серьезного заказчика не прокатит.
G>>Ну то есть ты приемкой то и не занимаешься, просто передастом работаешь. G>>Фактически качество кода подрядчиков контролирует только тестер. SK>ну оно конечно можно, чтобы все делал один человек. И код писал и тестировал работу подрядчиков и руководил проектом и еще там бухгалтерию вел и все в сроки успевал, только если и будет такой человек, то стоить он будет столько, что дешевле нанять все-таки 4х. Если кто-то думает, что руководитель проекта просто чай на работе гоняет, то он глубоко заблуждается. Поэтому еще раз повторюсь, времени у меня на чтение кода, к тому же чужого.
Если ты РП, то тебе и не нужно это делать. Но это значит что не ты занимаешься приемкой, а тестер.
Моя практика показала что тестеры плохо с этим справляются. Слишком мало они находят и слишком медленно это делают.
Тестеры эффективно работают как UAT, а за качество отвечают программисты, в том числе за качество кода подрядчиков.
Здравствуйте, gandjustas, Вы писали:
G>Затем что основные затраты на софт идут на этапе эксплуатации, появляются баги и всякие мелочи, которые надо поправить, очень большую роль играет UX и надежность кода при изменении параметров среды. G>Причем тестировать все это непозволительно долго. G>За свою практику я не видел кода, для которого было бы достаточно удовлетворения только функциональной спецификации. G>Да и банально review ловит больше ошибок, чем тестирование.
По моему опыту ревью ловит только стилистические отклонения от Code Standard и потенциальные ошибки, которые просто бросаются в глаза (типа неуместного использования new/delete в С++ коде).
Но такое встречается только у совсем начинающих.
Чтобы выявить более серьезные ошибки приходится вникать в код, понимать, какую задачу этот код решает, как ее решает. А обычно каждый решает свою задачу, на выяснение, чем занимаются вокруг, времени нет. Т.е. трудозатраты на ревью получаются лишь немногим меньше, чем написание этой функциональности с нуля самостоятельно. И на такое никто время не выделяет.
Поэтому согласен со SkyKnight, что за внутренности плагина пусть отвечает исполнитель, главное, чтобы тесты проходили.
_____________________
С уважением,
Stanislav V. Zudin
SD>Речь про предыдущего менеджера, который к этому кризису привёл.
То есть, пригласили тебя как кризис-менеджера разрулить ситуацию. Ты посмотрел и говоришь,
что нужно уволить предыдущего менеджера по четырем причинам.
Того менеджера уже нет, отвечают тебе. Тебя и пригласили поэтому, собственно говоря.
А вопрос в том, что делать в сложившейся ситуации.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Здравствуйте, gandjustas, Вы писали:
G>>Затем что основные затраты на софт идут на этапе эксплуатации, появляются баги и всякие мелочи, которые надо поправить, очень большую роль играет UX и надежность кода при изменении параметров среды. G>>Причем тестировать все это непозволительно долго. G>>За свою практику я не видел кода, для которого было бы достаточно удовлетворения только функциональной спецификации. G>>Да и банально review ловит больше ошибок, чем тестирование.
SVZ>По моему опыту ревью ловит только стилистические отклонения от Code Standard и потенциальные ошибки, которые просто бросаются в глаза (типа неуместного использования new/delete в С++ коде).
Это значит что ты код смотрел, а не читал.
SVZ>Чтобы выявить более серьезные ошибки приходится вникать в код, понимать, какую задачу этот код решает, как ее решает. А обычно каждый решает свою задачу, на выяснение, чем занимаются вокруг, времени нет. Т.е. трудозатраты на ревью получаются лишь немногим меньше, чем написание этой функциональности с нуля самостоятельно. И на такое никто время не выделяет.
"лишь немногим меньше" — в 4-6 раз примерно. Можно и быстрее ревью делать, но тогда ошибки проскакивают.
А еще можно ревью автоматизировать тулами, тогда анализ кода делается примерно в 10 раз быстрее, если код написан нормально.
SVZ>Поэтому согласен со SkyKnight, что за внутренности плагина пусть отвечает исполнитель, главное, чтобы тесты проходили.
Ну кому как...
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, kostik78, Вы писали:
K>>Если это кризис менеджер — то на мой взгляд вывод простой. Предоставить развернутый анализ текущей ситуации вышестоящемоу менеджеру и вынести предложение об увеличений срока проекта и уволнений програмиста.
_AB>Примерно так бы я и поступил будь я на его месте. Но я не программист и не менеджер. _AB>И есть в связи с этим у меня один вопрос ниже.
K>>Принимать решение в данной ситуации самому менеджеру не стоит.
_AB>Зачем нужен менеджер, если он боится принимать решения в рамках своей компетенции? _AB>Или это не его компетенция? Но тогда он скорее аудитор, а не менеджер получается?
Дело не в компетенции и не в том что боится принимать решения. Его пригласили со стороны и он может не знать всех тонкостей проекта и какие бизнес причины для него. То бишь самому менеджеру сложно оценить все аспекты и возможные последствия того или иного решения. Также проект уже в состояния "риска" — значит менеджеру стоит позаботится о своем "заднем месте". Либо получить "индульгенцию" от вышестоящего менеджемнта, либо шарить респонсибилити на принятое решение. Это как бы сделал я будучи на месте этого менеджера Но мои действия базируются на моем 6-летнем опыте управления 30+ подчиненными (4 тима) в западной компании. В России реалити бизнеса немного другие.
Здравствуйте, enji, Вы писали:
E>Наткнулся на интересное
E>Вкратце: E>
E>Есть проект, который уже пол года выполняет сторонняя ИТ-фирма подрядчик.
E>А программист Д – с нашей стороны приемщик работ, текстов и всего проекта.
E>Месяц назад они — наш программист и подрядчик поссорились.
E>Теперь программист решил всем назло, сделать всё самостоятельно с помощью одного своего помощника.
E>...
E>Позиция программиста:
E>Я же сам готов всё сделать. Это будет бесплатно и гораздо лучше, чем сделает подрядчик.
E>Нужно немедленно разорвать контракт с подрядчиком.
E>Тогда я (программист) берусь все сделать через месяц и совершенно бесплатно ( за зарплату), только ко мне никто не должен лезть и мешать.
...
E>Вопрос классический:
E>- Что делать?
Самое интересно, из-за чего "поссорились" программист и подрядчик. Они что, за разные футбольные клубы болеют? Скорее всего программисту чем-то не понравился результат работы подрядчика. Так что почему бы не заставить подрядчика сделать работу так, как это требует программист? Пригрозив разрывом контракта.
А то получается, что сначала фирма поставила программиста рулить подрядчиком, а потом в возникшем конфликте заняла сторону подрядчика. Директор кому больше доверяет — своему сотруднику или подрядчику? Если директор сам больше знает, то пусть увольняет программера и сам добивает проект.
Сейчас у фирмы два варианта: либо сказать "Я начальник — ты дурак", либо сказать "Клиент всегда прав". Чтобы принять решение, нужно определиться, кто объективно прав в возникшем конфликте, кто предлагает лучшее решение. Для этого нужно обратиться к сторонним экспертам-технарям — пусть они оценят качество решений, предлагаемых программистом и подрядчиком.
Здравствуйте, Mazay, Вы писали:
M>Сейчас у фирмы два варианта: либо сказать "Я начальник — ты дурак", либо сказать "Клиент всегда прав". Чтобы принять решение, нужно определиться, кто объективно прав в возникшем конфликте, кто предлагает лучшее решение. Для этого нужно обратиться к сторонним экспертам-технарям — пусть они оценят качество решений, предлагаемых программистом и подрядчиком.
Насколько я понял ТС и является этим сторонним экспертом-технарем (точнее уже не сторонним).
Здравствуйте, Mazay, Вы писали:
M>Самое интересно, из-за чего "поссорились" программист и подрядчик. Они что, за разные футбольные клубы болеют? Скорее всего программисту чем-то не понравился результат работы подрядчика. Так что почему бы не заставить подрядчика сделать работу так, как это требует программист? Пригрозив разрывом контракта.
M>А то получается, что сначала фирма поставила программиста рулить подрядчиком, а потом в возникшем конфликте заняла сторону подрядчика. Директор кому больше доверяет — своему сотруднику или подрядчику? Если директор сам больше знает, то пусть увольняет программера и сам добивает проект.
тут два варианта:
1) подрядчик откатил директору или каким-то другим образом является аффилированным
2) ранее мнение программиста демонстративно проигнорировали или каким-то другим образом задели его самолюбие
Возможно что оба сразу.
M>Сейчас у фирмы два варианта: либо сказать "Я начальник — ты дурак", либо сказать "Клиент всегда прав". Чтобы принять решение, нужно определиться, кто объективно прав в возникшем конфликте, кто предлагает лучшее решение. Для этого нужно обратиться к сторонним экспертам-технарям — пусть они оценят качество решений, предлагаемых программистом и подрядчиком.
В первую очередь надо думать как проект в срок сдать, а не выяснять кто прав.
Здравствуйте, Mazay, Вы писали:
M>Самое интересно, из-за чего "поссорились" программист и подрядчик. Они что, за разные футбольные клубы болеют? Скорее всего программисту чем-то не понравился результат работы подрядчика. Так что почему бы не заставить подрядчика сделать работу так, как это требует программист? Пригрозив разрывом контракта.
Если комменты почитать, то да, там примерно так и было. Конфликт этот уладили.
M>А то получается, что сначала фирма поставила программиста рулить подрядчиком, а потом в возникшем конфликте заняла сторону подрядчика. Директор кому больше доверяет — своему сотруднику или подрядчику? Если директор сам больше знает, то пусть увольняет программера и сам добивает проект.
Основная проблема с этим программером, что он рогом уперся и не хочет работать с подрядчиком, а хочет сам писать всё с нуля.
Предыдущий конфликт (в котором была вина подрядчика) улажен.
1/14/2014 8:47 PM, gandjustas пишет:
> В первую очередь надо думать как проект в срок сдать, а не выяснять кто > прав.
Вообще от в первую очередь тут надо думать о том, как прикрыть свою задницу.
1/14/2014 9:00 PM, _ABC_ пишет:
> Основная проблема с этим программером, что он рогом уперся и не хочет > работать с подрядчиком, а хочет сам писать всё с нуля. > Предыдущий конфликт (в котором была вина подрядчика) улажен.
Значит снимайте его с этого проекта — выбора все одно нет.
Тем более, если с заказчиком вопросы решены.
G>Ну то есть ты приемкой то и не занимаешься, просто передастом работаешь. G>Фактически качество кода подрядчиков контролирует только тестер.
Это некорректное заявление. Прежде, чем тестер что-то протестирует, это "что-то" должно стать явным и известным. Иными словами, чтобы тестер стал тестировать вот такой-то сценарий, этот сценарий должен быть где-то описан, зафиксирован, запротоколирован и т.п.. Это достаточно сложная и ответственная работа — выбрать с одной стороны минимальный, с другой — охватывающий все важные функциональные моменты набор. А также их приоретизировать.
В конечном итоге тестер вряд ли все это делает руками. Обычно его работа состоит в том, чтобы запрограммировать сценарий и добавить тест в набор автоматического билда.
