Вчера друг рассказал две истории из его большого опыта работы в крупной оффшорной конторе. Обе о том, с каким трепетом некоторые заказчики (а они же являются владельцами производимого оффшорщиками кода) относятся к результатам работы разработчиков.
История первая. Делается незначительный рефакторинг некоего второстепенного и совершенно не публичного класса – какой-то метод переименовывается, какой-то удаляется, а на его место добавляются пара новых методов. Изменения фиксируются в репозитории. Спустя пару часов от заказчика приходит письмо с просьбой объяснить, зачем и почему были сделаны такие изменения.
Увидев мои круглые глаза друг рассказал еще более замечательный случай. Его коллега руководил проектом для другого заказчика и был вынужден тратить по четыре(!) часа в день только на объяснению заказчику причин внесения в код тех или иных изменений.
Ну что тут сказать… Маразм крепчал, конечно. Но, с другой стороны, как даму обедают, так ее потом и танцуют. Вот хотят танцевать именно так – что остается делать? Поэтому от оффшорных контор лично я стараюсь держаться подальше. Имхо, если уж разрабатывать софт на дядю, то там, где этот дядя сам является владельцем разрабатываемого софта. И живет с этого софта. А не с проданных жопочасов.
8 комментариев:
Таким вопросом может задаваться человек, который не работал на реально большом проекте, где цена ошибки настолька велика, что способна снизить кредит доверия к компании. Пример - ошибки в софте от Тойоты, когда отзывается вся партия авто. Или партия телефонов. Или, не дай бог, софт какого-нибудь лайф сэйвинг устройства.
Кроме того - это иногда неплохая тренировка, пообщаться с ситемным инженером или архитекторам и объяснить причину твоего изменения. Заставляет все обдумать и взвесить.
А в горомадных проектах, внося изменения, ты реально можешь не всегда представлять последствия твоего, как тебе кажеться, мизерного изменения.
и, кстати, это положение не вечно :)
со временем, такие проверки пропадают - уж поверь :)
это своеобразный вызов на качество твоей работы
Мне кажется тут не проверяется качество кода - не верю, что заказчик может найти ошибку в коде при простом объяснении, зачем эти изменения были внесены. Если это так, то можно увольнять программистов, которые такие явные вещи не заметили. Я думаю тут боятся внесения бэкдоров и тому подобных вещей, которыми потом разработчики могут давить на заказчика. Если человек не может ясно объяснить внесенные им изменения, вполне вероятно, что он не хочет говорить истенные причины.
> это своеобразный вызов на качество твоей работы
Качество работы - это приложение работающие 24/7 без сбоев и полностью устраивающее конечного пользователя. ИМХО.
@Sanik:
твоя мысль понятно, спасибо, я такой аспект во внимание не принимал.
В свою защиту могу сказать, что там никакими особо важными проектами не пахло. Обычное корпоративное порталостроительство.
Если же речь идет об обеспечении надежности, то, мне кажется, заказчик должен был бы больше уделять внимания списку тестов, программе приемосдаточных испытаний, более четким спецификациям и, даже, верификации кода.
Тогда бы и разработчик был более свободен при написании кода (нет мелочного контроля вроде споров Timestamp getCurrentTime() vs void getCurrentTime(Timestamp &)), и заказчик более спокоен, поскольку код проходит заявленные тесты.
@4ybaka вы неправы. очень даже могут. по счастью мне довелось работать со множеством ярких инженеров на той стороне провода.
@Blob я это и имел ввиду. только вам нужно будет доказать, что вы способны на такое качество.
@eao197 как я уже сказал - есть время на притирку. позже тебе дадут ту степень свободы, которую ты заслужишь. и, очень вероятно, будут прислушиваться к твоему мнению :)
@Sanik:
похоже, тебе весьма повезло с заказчиками. На той стороне, видимо, были грамотные инженеры и менеджеры, которые активно принимали участие в разработке продукта.
Я был наслышан о других ситуациях. Когда владелец софта после кризиса 2001 года практически не оставил в своем штате технических спецов. Т.е. от владельца-заказчика исходили только пожелания, требования и сроки. Все остальное отдавалось на откуп аутсорсерам.
И у меня сложилось впечатление, что это не такая уж и крайность в оффшоре.
@Евгений в сайтостроении - очень даже просто :) с оффшором/аутсорсингом проблема - ты пожизни зависим от контракта.
Отправить комментарий