Comments 28
Эх, а я прочитал Fast Driven Development
«С момента написания топика события сдвинулись с мертвой точки»
Кажется я догадываюсь, чем именно занимался разработчик дома =))
Кажется я догадываюсь, чем именно занимался разработчик дома =))
Разработка, основанная на вере? Подозреваю, что этот ваш Java-девелопер деньги требовал сразу и на регулярной основе…
А дело сдвинулось наверное потому, что его из дома выгнали, да? :)
А дело сдвинулось наверное потому, что его из дома выгнали, да? :)
«одно исправил – другое сломалось»
Тесты. У вас есть тесты?
Тесты. У вас есть тесты?
Основная ваша проблема была вот в этом:
«Якобы, чтобы не отвлекаться от процесса разработки он даже перешел на работу из дома.»
Так не годится. Возможно ваш человек действительно «Специалист» но в домашних условиях практически невозможно настроится на продуктивную работу.
Знаю по себе потому что сам фрилансер и если хочу поработать иду куда угодно но не в родные стены.
Пусть бы он работал 4 часа в день, но не дома а у вас в офисе и продуктивность поверьте выросла бы многократно.
Если уж он действительно говорит что ему проще и удобнее работать на дому, тогда просто составляется график работ. Вы у него спрашиваете «Чем ты сейчас будешь заниматься и сколько это займет по времени?», если он ответит «Ну я не знаю, надо сделать то и то и то...», сразу говорите, опять же, что так не годится. Пусть делит эту работу на блоки и каждый блок описывает, «что он делает» и «и сколько по времени».
Работа пойдет значительно шустрее.
«Якобы, чтобы не отвлекаться от процесса разработки он даже перешел на работу из дома.»
Так не годится. Возможно ваш человек действительно «Специалист» но в домашних условиях практически невозможно настроится на продуктивную работу.
Знаю по себе потому что сам фрилансер и если хочу поработать иду куда угодно но не в родные стены.
Пусть бы он работал 4 часа в день, но не дома а у вас в офисе и продуктивность поверьте выросла бы многократно.
Если уж он действительно говорит что ему проще и удобнее работать на дому, тогда просто составляется график работ. Вы у него спрашиваете «Чем ты сейчас будешь заниматься и сколько это займет по времени?», если он ответит «Ну я не знаю, надо сделать то и то и то...», сразу говорите, опять же, что так не годится. Пусть делит эту работу на блоки и каждый блок описывает, «что он делает» и «и сколько по времени».
Работа пойдет значительно шустрее.
Основная и единственная ошибка — полное отсутствие руководства. Нет ни графиков работ, ни контроля выполнения, ни штрафных санкций за просрочки и т.п.
При грамотном контроле работа из дома может быть продуктивнее. Но этого никогда не случится без нормального руководства.
Так или иначе, если у вас есть офис, то при появлении проблем надо было переводить этого работника на полный рабочий день в офисе.
При грамотном контроле работа из дома может быть продуктивнее. Но этого никогда не случится без нормального руководства.
Так или иначе, если у вас есть офис, то при появлении проблем надо было переводить этого работника на полный рабочий день в офисе.
У нас есть трекер, через который проходят все задачи. Проблема на самом деле в том, что не смотря на закрываемые (то есть, якобы выполненные) задачи, функционал не работает как следует. Закрыл (выполнил) фичу — открывается несколько багов по этой фиче. И так по кругу в течение нескольких месяцев.
ну так кто мешал контролировать такое поведение? если такое продолжалось по кругу — почему сразу не поднимался вопрос? почему, при таких сжатых сроков, не делали delivery каждую неделю или каждую вторую неделю? расписали, должно быть готово 1/20 функционала к концу недели — в пятницу — delivery с тестами, review, и по новой.
у вас абсолютно не была поставлена ни контроль над «специалистом», ни контроль над проектом, ни контроль над кодом — да просто ничего. лучше бы пожертвовали все деньги на благотворительность, чем просто просрали из за отутствия контроля и менеджмента.
у вас абсолютно не была поставлена ни контроль над «специалистом», ни контроль над проектом, ни контроль над кодом — да просто ничего. лучше бы пожертвовали все деньги на благотворительность, чем просто просрали из за отутствия контроля и менеджмента.
Наиболее частый и самый желехобетонный аргумент «специалиста» — «у меня все работает». Он разработчик серверной части проекта. Когда наработки по задаче переходили клиентскому разработчику и тот заканчивал свою часть работы, оказывалось, что на сервере либо вообще не работает, либо глючит.
В итоге мы имеем кучу недоделанного функционала. Кода много, толку никакого.
В итоге мы имеем кучу недоделанного функционала. Кода много, толку никакого.
Ну так заставляйте писать тесты, в чем проблема-то? Серверная часть легко тестируется. Нельзя пускать все на самотек.
это не ответ — у каждого проекта, каким бы он не был большим или малым должен быть тим лид/прожект менеджер, при чем на вашей стороне, который контролирует качество проекта, принимает этапы от удаленщиков и т.д.
нужен четкий план проекта, точнее цели. нужно расписать этапы, с таким сроком и с таким «специалистом» этапы длиною в неделю/две. ставить условие — без тестов твой код говно и не принимать. review делать тестов (сам код можно не смотреть). в зависимости от прогресса корректировать план. это все азы agile разработки. проект 100% не удасться завершить в срок когда так все запущено, но не будет сюрпризов через 4 месяца — что ничего не работает.
у вас нет процесса — хотите его получить, могу проконсультировать — пишите в личку.
нужен четкий план проекта, точнее цели. нужно расписать этапы, с таким сроком и с таким «специалистом» этапы длиною в неделю/две. ставить условие — без тестов твой код говно и не принимать. review делать тестов (сам код можно не смотреть). в зависимости от прогресса корректировать план. это все азы agile разработки. проект 100% не удасться завершить в срок когда так все запущено, но не будет сюрпризов через 4 месяца — что ничего не работает.
у вас нет процесса — хотите его получить, могу проконсультировать — пишите в личку.
Ну, и не забываем про мотивацию.
По моему опыту — при работе с удаленщиками, оплата по факту (точнее, её задержка при непрохождении верификации фичи) — очень мотивирует исполнителя.
Если же он хочет непременно оклад и отказаться от него никак нельзя (уж больно парень хороший) — тогда план на месяц — выполнение — выплата оклада, либо штрафные санкции.
Еще одна ваша проблема (это я автору поста), в том, что вы фичи расцениваете как сферическую задачу в вакууме, которую надо «закрыть», а потом «искать баги». Это ошибка. Фича — это кусок функционала, имеющий определенную пользу. Если фича закрыта — необходимо провести её верификацию. Если специальных тестировщиков для этого не выделено, то можно воспользоваться следующим проверенным способом.
Верификацию фичи переложить на хрупкие плечи разработчика, при этом его сразу предупредить, что словам вы не поверите, а поверите только материальным свидетельствам (скриншотам, видео-роликам, логам), которые ясно и неоднозначно показывают, что фича работает.
По моему опыту — при работе с удаленщиками, оплата по факту (точнее, её задержка при непрохождении верификации фичи) — очень мотивирует исполнителя.
Если же он хочет непременно оклад и отказаться от него никак нельзя (уж больно парень хороший) — тогда план на месяц — выполнение — выплата оклада, либо штрафные санкции.
Еще одна ваша проблема (это я автору поста), в том, что вы фичи расцениваете как сферическую задачу в вакууме, которую надо «закрыть», а потом «искать баги». Это ошибка. Фича — это кусок функционала, имеющий определенную пользу. Если фича закрыта — необходимо провести её верификацию. Если специальных тестировщиков для этого не выделено, то можно воспользоваться следующим проверенным способом.
Верификацию фичи переложить на хрупкие плечи разработчика, при этом его сразу предупредить, что словам вы не поверите, а поверите только материальным свидетельствам (скриншотам, видео-роликам, логам), которые ясно и неоднозначно показывают, что фича работает.
Видимо тут сыграло то, что этот товарищ был не с улицы, а хороший знакомый руководителей проекта. Ему отдали все ТЗ с формулировкой «Мы тут хотим вот такой проект сделать, ждем результатов». Парень понял, что деньги ему платят, а результатом только робко интересуются из разряда «ну как там дела с игрушкой?». Все потому, что ему доверяли.
За предложение проконсультировать искреннее спасибо, но ситуация в каком-то виде разрешилась. О чем я уже пишу продолжение топика ^_^
За предложение проконсультировать искреннее спасибо, но ситуация в каком-то виде разрешилась. О чем я уже пишу продолжение топика ^_^
А от этого в принципе никуда не деться. Проблемы всегда будут находится. Стандартные законы Мэрфи.
Просто все это нужно учитывать при построении задачи.
Да и еще одно забыл дописать в прошлом комменте.
Один из законов Мэрфи гласит:
«Если на вашем предприятии работает незаменимый человек, Лучшее что вы можете сделать это уволить его.»
Под завуалированностью поговорки просто хочу вас предупредить! ОДИН ЧЕЛОВЕК НЕ ДОЛЖЕТ БЫТЬ ЯДРОМ!
Вы бы лучше на старте взяли его как руководителя программерского отдела. А его задачу передали в руки нескольких не столь одаренным товарищам и пусть они бы организовывали мозговой штурм.
Вы как сервер на котором не делается Back-up. Авось ваш «Специалист» пойдет в казино снимет джек-пот, и забъет на все, а у вас потом уйдут долгие недели или того больше чтобы собрать все и разобраться в его коде.
Просто все это нужно учитывать при построении задачи.
Да и еще одно забыл дописать в прошлом комменте.
Один из законов Мэрфи гласит:
«Если на вашем предприятии работает незаменимый человек, Лучшее что вы можете сделать это уволить его.»
Под завуалированностью поговорки просто хочу вас предупредить! ОДИН ЧЕЛОВЕК НЕ ДОЛЖЕТ БЫТЬ ЯДРОМ!
Вы бы лучше на старте взяли его как руководителя программерского отдела. А его задачу передали в руки нескольких не столь одаренным товарищам и пусть они бы организовывали мозговой штурм.
Вы как сервер на котором не делается Back-up. Авось ваш «Специалист» пойдет в казино снимет джек-пот, и забъет на все, а у вас потом уйдут долгие недели или того больше чтобы собрать все и разобраться в его коде.
Это не Faith-driven development, это Ass-driven development.
Знакомая ситуация:( вот только проект даже до альфы не дожил
Расскажите поподробнее о вашей ситуации. В чем были основные ошибки?
На мой взгляд основная ошибка была в том что ведущий программист был один все это осложнялось его коммуникативными барьерами. Проект не коммерческий, найти еще одного программиста не представлялось возможным, не говоря уже про замену. Сроки срывались, но работа шла и это вселяло надежду, но в конечном итоге сам уже не видя ни цели не результата он отказался работать над проектом. Вобщем когда весь проект завязан на одном человеке который не в состоянии приложить достаточное количество усилий это путь в никуда.
> Код проекта оставляет желать лучшего, никакого проектирования архитектуры не было, посему когда исправляется что-то одно – ломается другое.
ищите еще одного знакомого-архитектора, которые спроектирует
ищите еще одного знакомого-архитектора, которые спроектирует
Sign up to leave a comment.
Faith-driven development