Вы двигаетесь в правильном направлении — чем точнее описана задача, тем меньше багов будет в последствии и тем меньше нужно будет переделывать.
На основании своего опыта могу сказать, что вам все же надо стремиться к тому, чтобы писать описание к задачам, причем писать его с достаточной степенью детализации. Я считаю, что в вашем случае пробема в «ТЗ устареет еще раньше, чем будет написано» — учитесь писать ТЗ быстро, иначе будете больше времени тратить на правку багов и доработки, чем на новый функционал. Перед распределением задач по разработчикам обязательно обсуждайте задачи с тимлидом, чтобы он мог дополнить это самое ТЗ (Тим лид в свою очередь может привлекать разработчиков, ответственных за тот или иной кусок системы). При передече задачи давайте прочесть ТЗ и обсуждайте детали реализации с исполнителем, дабы убедиться что он все понял и чтобы у него была возможность задать вопрос.
Я работал как в большой компании, где задачи описывались долго и подробно, и там вообще не было ситуаций, когда всплывали недоработки какие-то (кроме супер сложной корзины товаров крупной торговой площадки, где разработка была на полтора месяцв нескольких людей и сложно было все учесть).
Был и в стартапе с недельными/двухнедельными спринтами, где было 2 команды. В нашей команде задачи давались хорошо (достаточно) описанными и проработанными, и переделывать что-то или менять в процессе ничего особо не приходилось. Багов конечно тоже было много, но они были следствием говнокода, доставшегося от начавших проект людей.
В другой команде задачи давались так, что программистам приходилось самим разбираться что и как делать — итог был весьма печален — чуть ли не больше половины времени уходило на правку багов и доработки того, что работает не так, как надо. Как-то раз в нашу команду пришла «срочная» не маленькая задача, но она была плохо проработана, требования менялись на пути, были критичные ошибки в описании workflow по задаче. Скажу, что кроме намного большего количества багов, задача фактически потратила дорогое время кучи народа, только потому, что изначально PM не правильно понял workflow.
Как мы сможем это узнать?
Просто сейчас это выглядит так:
«Ребят я с ребятами учредил сервис example.com, по оценке он сейчас стоит $1 триллион».
Это я к тому, что интересно было бы было прочесть хотя бы в общих чертах как оценили компанию. Из той информации которая имеется, какие-либо выводы сделать сложно, тем более что некое соглашение с некими Кредитными бюро почти ни о чем не говорит.
Проинвестировать через вашу же платформу деньги в сайт который вы сами оценили в $600 тыс.?
Ммм, заманчиво конечно… А почему не пошли искать посевные инвестиции в венчурные фонды, которые еще и помочь могут не только деньгами?
Помнится как мне дали бесплатно бф3 за проблемы с доступом в сим сити новый… И потом через месяцок забанили, за то что у меня угнали аккаунт. Причем между угоном и сбросом пароля прошло около 5 минут, но за это время то ли злоумышленник что-то сделал, то ли они просто сам факт взлома запалили. В итоге по их политике, мой аккаунт был «involved in hacking» и ссылаясь на это они меня послали куда подальше…
Прошу прощения, бес попутал — не знаю почему решил что вы топикстартер.)))
Ну я сказал, что натравил бы в данном случае инспекцию и рассказал бы заказчику о «внутренней кухне» такой компании, на всякий случай, чтобы их обезопасить. И так же вы путаете производство и перевозку — всё таки разные вещи.
Вот если бы я произвёл на 50 рублей товара, а явно ложью и манипуляциями различными мне всё время платили бы 30 рублей — я не считаю зазорным оставить себе товара на 20 рублей — не заплатили мне, значит они эту часть моего труда, выраженного в конкретном продукте не купили…
В случае с кодом, если бы меня так сильно пытались нагнуть как автора, (и писалось бы не для внешнего заказчика — он из-за наших дрязг страдать не должен) я спокойно оформил бы авторские права и уже по другому разговаривал бы с таким работодателем. Конечно стал бы просить только недоплаченное, ибо иначе это был бы шантаж неоправданный, который как раз, по моему мнению уже мудацтво.
Немного сумбурно наверное написал, но голова под вечер гудит.
Погодите, вот если у вас украли деньги путем мошенничества, например, вы не будете в суд подавать чтобы мудаком не быть?
Конечно я вас не призываю делать, что предложили постом выше, но по другой причине, которую уже озвучил — из-за заказчика.
Просто поступать по справедливости я не считаю зазорным, поэтому удивляюсь. Видимо завет про подставление другой щеки не про меня. Я в таких ситуациях считаю правильным следовать следующему принципу — «Не будь бессердечным, прости первый раз, не будь глупым, не терпи второй\третий». Другими словами если что-то не так, предупрежу, а потом уже моя совесть чиста будет, если человек не одумался.
Но есть и другое но — всё зависит от ситуации. Это не значит что будет вендетта первому обидевшему человеку. Но в таком случае как ваш я бы предложил от меня отстать, иначе натравил бы всякие инспекции на них, и уж тем более рассказал бы про внутреннюю кухню конечному заказчику, чтобы были готовы если что, тем более что там люди адекватные судя по всему.
Это конечно да, но по идее по законодательству тому же, даже если приставка твоя, то не факт что вы имеете право делать что-то кроме использования ПО.
Хотя конечно представить себе ситуацию когда уже за это будут судить, довольно сложно, но к сожалению, в нашей стране всё же реально.
Производительность shared-папок в Vagrant
В конфиге просто указано:
Особенно разительна разница в проектах на Symfony2 (php)
Записки арт-директора самоучки: не рычите на программиста
На основании своего опыта могу сказать, что вам все же надо стремиться к тому, чтобы писать описание к задачам, причем писать его с достаточной степенью детализации. Я считаю, что в вашем случае пробема в «ТЗ устареет еще раньше, чем будет написано» — учитесь писать ТЗ быстро, иначе будете больше времени тратить на правку багов и доработки, чем на новый функционал. Перед распределением задач по разработчикам обязательно обсуждайте задачи с тимлидом, чтобы он мог дополнить это самое ТЗ (Тим лид в свою очередь может привлекать разработчиков, ответственных за тот или иной кусок системы). При передече задачи давайте прочесть ТЗ и обсуждайте детали реализации с исполнителем, дабы убедиться что он все понял и чтобы у него была возможность задать вопрос.
Я работал как в большой компании, где задачи описывались долго и подробно, и там вообще не было ситуаций, когда всплывали недоработки какие-то (кроме супер сложной корзины товаров крупной торговой площадки, где разработка была на полтора месяцв нескольких людей и сложно было все учесть).
Был и в стартапе с недельными/двухнедельными спринтами, где было 2 команды. В нашей команде задачи давались хорошо (достаточно) описанными и проработанными, и переделывать что-то или менять в процессе ничего особо не приходилось. Багов конечно тоже было много, но они были следствием говнокода, доставшегося от начавших проект людей.
В другой команде задачи давались так, что программистам приходилось самим разбираться что и как делать — итог был весьма печален — чуть ли не больше половины времени уходило на правку багов и доработки того, что работает не так, как надо. Как-то раз в нашу команду пришла «срочная» не маленькая задача, но она была плохо проработана, требования менялись на пути, были критичные ошибки в описании workflow по задаче. Скажу, что кроме намного большего количества багов, задача фактически потратила дорогое время кучи народа, только потому, что изначально PM не правильно понял workflow.
Новейшая кредитная история или путеводитель по банкам от Bankle.ru
Просто сейчас это выглядит так:
«Ребят я с ребятами учредил сервис example.com, по оценке он сейчас стоит $1 триллион».
Это я к тому, что интересно было бы было прочесть хотя бы в общих чертах как оценили компанию. Из той информации которая имеется, какие-либо выводы сделать сложно, тем более что некое соглашение с некими Кредитными бюро почти ни о чем не говорит.
Новейшая кредитная история или путеводитель по банкам от Bankle.ru
Ммм, заманчиво конечно… А почему не пошли искать посевные инвестиции в венчурные фонды, которые еще и помочь могут не только деньгами?
Бесплатная копия Battlefield 3
Рассекречена личность Сатоси Накамото
Рассекречена личность Сатоси Накамото
Рассекречена личность Сатоси Накамото
Рассекречена личность Сатоси Накамото
Обнаружен ботнет, состоящий из «умных» телевизоров, медиацентров, ПК и… холодильника
Fallout 1, 2 и Tactics бесплатно
Fallout 1, 2 и Tactics бесплатно
Новый игровой ПК от Gigabyte помещается на ладони
Новые «жертвы» антипиратского закона: «Игра престолов» и другие сериалы
Youtube
Как я систему безопасности для авиакомпании разрабатывал и сам оказался в опасности
Ну я сказал, что натравил бы в данном случае инспекцию и рассказал бы заказчику о «внутренней кухне» такой компании, на всякий случай, чтобы их обезопасить. И так же вы путаете производство и перевозку — всё таки разные вещи.
Вот если бы я произвёл на 50 рублей товара, а явно ложью и манипуляциями различными мне всё время платили бы 30 рублей — я не считаю зазорным оставить себе товара на 20 рублей — не заплатили мне, значит они эту часть моего труда, выраженного в конкретном продукте не купили…
В случае с кодом, если бы меня так сильно пытались нагнуть как автора, (и писалось бы не для внешнего заказчика — он из-за наших дрязг страдать не должен) я спокойно оформил бы авторские права и уже по другому разговаривал бы с таким работодателем. Конечно стал бы просить только недоплаченное, ибо иначе это был бы шантаж неоправданный, который как раз, по моему мнению уже мудацтво.
Немного сумбурно наверное написал, но голова под вечер гудит.
Как я систему безопасности для авиакомпании разрабатывал и сам оказался в опасности
Конечно я вас не призываю делать, что предложили постом выше, но по другой причине, которую уже озвучил — из-за заказчика.
Просто поступать по справедливости я не считаю зазорным, поэтому удивляюсь. Видимо завет про подставление другой щеки не про меня. Я в таких ситуациях считаю правильным следовать следующему принципу — «Не будь бессердечным, прости первый раз, не будь глупым, не терпи второй\третий». Другими словами если что-то не так, предупрежу, а потом уже моя совесть чиста будет, если человек не одумался.
Но есть и другое но — всё зависит от ситуации. Это не значит что будет вендетта первому обидевшему человеку. Но в таком случае как ваш я бы предложил от меня отстать, иначе натравил бы всякие инспекции на них, и уж тем более рассказал бы про внутреннюю кухню конечному заказчику, чтобы были готовы если что, тем более что там люди адекватные судя по всему.
Как я систему безопасности для авиакомпании разрабатывал и сам оказался в опасности
Скорее не факт что справедливо будет по отношению к заказчику публиковать код.
В России был впервые осужден человек за прошивку Xbox 360, а затем оправдан!
В России был впервые осужден человек за прошивку Xbox 360, а затем оправдан!
Хотя конечно представить себе ситуацию когда уже за это будут судить, довольно сложно, но к сожалению, в нашей стране всё же реально.