для крупных задач можно регулярно спрашивать на каком этапе, в любом случае - во время работы будут вопросы, обсуждения - по ним видно, что человек работает
Да, хорошая штука для самоорганизации. Ни кто этим не пользуется на практике из присутствующих? Я в блокноте последнее время делаю пометки, сколько ушло времени, особенно на переговоры с заказчиком, как ни странно, т.к. они зачастую не хотя это время учитывать, как рабочее Видел на просторах инета скрины с xls таблиц, в примере ниже, одного дизайнера: Спрашиваю, т.к. давненько уже вынашиваю мысль написать очередной велодесктоп прогу для мака, что-бы организовывать задачи в пректы и чекать по ним время вручную для дальнейшего анализа и отчётов, возможно с интеграциями с внешними сервисами, трекерами задач...
мы пользуемся трелло и таблицами из гуглодоков. таблицы быстрей заполнять и больше информации сразу перед глазами. но в трелло можно засовывать картинки/файлы. видимо поэтому ни то ни другое до конца не подходит
Я вот всё никак за свою PM-систему не возьмусь. Есть вещи, которые очень нужны (особенно с финансовым анализом связанные) и нигде не реализованы. Сейчас вот как раз начинает жаба душить платить за Target Process (начинали учёт задач на нём, но подходим к лимиту бесплатного использования), так что как раз актуальной очень задача стала
А с заказчиком ты как будешь объясняться? Так и скажешь - разраб подвел? Каким образом договор вас защитит от неисполнения подрядчиком обязательств? Договор предусматривающий жесткие штрафные санкции ни один нормальный разработчик не подпишет. Например в договорах, которые я заключаю штрафные санкции не могут превышать 20% от суммы контракта. Т.е. даже если на год просрочим сдачу - все что теряем это 20%. Если же по каким то причинам исполнитель вообще забил на проект - что же, он просто не получит денег. Но он и не работал - а следовательно остался при своих. Пострадал только заказчик, у которого сроки сорваны. Нормальная команда удаленных сотрудников и подрядчиков - это путь проб и ошибок. слабые звенья отсеятся, сильные - останутся.
Вот кстати такого, чтобы кто-то вообще забил, не было уже очень давно. В последнее время почти все ошибки, с которыми довелось столкнуться - это ошибки менеджмента, когда что-то неправильно посчитал, не обратил внимания на какой-то пунктик в ТЗ, который вырос в кучу человекочасов, и так далее. Ну и да, даже очень хорошему исполнителю нужен не менее хороший менеджер. Который имеет хорошее понимание проекта, ставит задачи с правильной стороны, где надо - подгонит, где надо - предложит решение. А когда разраб сам по себе, то теряется только в путь.
Есть такое. Но корни этой проблемы исходят как от исполнителя, так и от заказчиков. Хуже всего когда что-то делаешь не с нуля. От заказчика который говорит 'нам тут чуть-чуть поправить' хочется разу бежать. У нас была ситуация когда проект на который планировали 2-3 месяца ушло больше года. Обратился постоянный клиент, проекты которого были на поддержке. Ему требовалось сделать соц. сеть знакомств и досуга. Озвучили ему срок в один год, плюс-минус. Клиент взял паузу, а через месяц пришел с другим предложением. Он купил готовую соц. сеть, где уже все реализовано, но нужно немного допилить по нужды клиента. Движок пощупали все действительно работает, он коммерческий есть связь с разработчиками. Взяли проект в работу. Потом начался ад. В Рунете информации об этом движке ноль, в американском интренете кое-то нашли, но все на дилетантском уровне - вопросы типа как шаблоны сменить, формы поправить и т.д. Разработчикам этого чуда мы в первые две недели прислали полсотни баг репортов, после чего они слились и для общения с ними пришлось дергать заказчика. Потом забили исправляли своими силами. Предоставленная документация оказалась только на базовом уровне, а глубже разработчик делится инфой не желал, вместо этого предлагая свои услуги. Либо они сами не хотел трогать то, что уже хоть как-то работает. Потом у наших программистов возникло сомнение, что все это будет жить при больших нагрузках - тем более показанные разработчиком примеры реализованных проектов были полумертвыми - какие-то дохлые игровые порталы, университетские кампусы и т.д. Сообщили заказчику, его ответ, не важно, главное чтобы через три месяца хоть что-то работало - ему надо показать проект инвесторам. Потом похер - хоть два года пилите. Через три месяца свет увидел полуживой проект с 5000 юзерами (фрилансеры нарегали), а итог подвели только через 14 месяцев. За это время число задач выросло раза в три, а бюджет - в пять раз. Но скиллы прокачали офигенно.
Поэтому и требовали денег за доработки, это же естественно. У меня похожая ситуаця, ряд проектов на движке onPHP, у которого всё плохо с документацией, а разработчики давно забросили сие чудо инженерной мысли. Сделали форк, сами этот движок допиливаем по чуть чуть (namesapces, composer, переезд на php 7.0 и много других мелочей).
*> ежедневно копается в норах кривого legacy аж замироточил от слов "вот тут надо чуть-чуть логику поменять"
Ох и сформулировал на ночь глядя... не движок, а проекты на нём. У самого форка фиксим всплывающие ошибки, да дописываем недостающие "драйвера" к БД.