loading...
Привет!
Я – разработчик всяких разных интернет проектов. В последнее время ввиду активности заказчиков, пытаюсь собрать небольшую команду программистов (ситуация, я думаю, стандартная для многих). Так вот, весьма логично происходит так, что львиную долю времени сейчас я трачу на менеджмент, организацию рабочего процесса, взаимодействие с заказчиками и по ночам умудряюсь еще писать свой код. Собственно говоря я пишу к великому сообществу с надеждой получить какой то опыт вот в каком вопросе: когда проекты мелкие, оценить их на глаз довольно просто с учетом своего опыта и поправки на ветер (загруженность и опыт конкретного разработчика). Как вы оцениваете
Пришел заказчик, сформулировал задачу, вы даже разработали вместе ТЗ довольно обьемное. Проект типа платежный шлюз с обязательной сертификацией по PCI DSS.
С какой стороны подойти и как аргументировать?
Разбить на мелкие части и на глаз каждую?
А если какой-то из этапов подразумевает под собой какую то долю неопределенности в том, как ее разрабатывать именно?
Выручайте, мужики, очень рассчитываю на Ваш опыт!
Как вы оцениваете крупные проекты?,
не претендую на звание крутого проджект менеджера ибо на своих же ошибках учусь каждый день, до этого работал как рядовой и старший программист.
agile agile agile
Подготовить верхнеуровневый план релизов проекта, работать итерационно, потому что проект за время разработки может полностью поменяться. Денег просить за выполнение обозреваемых релизов.
Борьба с оценкой неопределенности — как уже сказано — происходит делением большой неопределенности на много маленьких, а также гибким ценообразованием — можно попробовать убедить клиента в том, что когда неопределенностей слишком много, для достижения реального результата разумней платить не за всю никому не известную пока систему, а за потраченное на ее разработку время специалистов.
Аргументы могут быть простые — «мы не знаем, что будет, вы не знаете, что будет; если нашей сегодняшней оценки стоимости не хватит, разработчики просто разбегутся и результата не будет никакого». Для того, чтобы у клиента не было сомнений в достоверности ваших отчетов о затраченном времени, ввести этапность работ, как сказано выше, и сдавать отчеты/получать деньги за понятные заказчику завершенные этапы.
о, спасибо за agile. ушел читать википедию и relative ресурсы
какие-то тулзы для проектирования кто-то использует может хорошие? возможно есть хорошие онлайн? azalo.net?
notepad рулит, а так же его продвинутый вариант – sublime text 2
для agile – versionone отлично подходит.
умные люди говорят, что самое рисковое и неопределенное делать первым. сам с таким не сталкивался.
Разбивай на куски, инкриментируй. Готовся к тому, что заказчик захочет по ходу изменить требования к проекту, потому что даже он не может 100% знать, что лучше в итоге.