GD Star Rating
loading...

Привет!

Я – разработчик всяких разных интернет проектов. В последнее время ввиду активности заказчиков, пытаюсь собрать небольшую команду программистов (ситуация, я думаю, стандартная для многих). Так вот, весьма логично происходит так, что львиную долю времени сейчас я трачу на менеджмент, организацию рабочего процесса, взаимодействие с заказчиками и по ночам умудряюсь еще писать свой код. Собственно говоря я пишу к великому сообществу с надеждой получить какой то опыт вот в каком вопросе: когда проекты мелкие, оценить их на глаз довольно просто с учетом своего опыта и поправки на ветер (загруженность и опыт конкретного разработчика). Как вы оцениваете крупные проекты?

Пришел заказчик, сформулировал задачу, вы даже разработали вместе ТЗ довольно обьемное. Проект типа платежный шлюз с обязательной сертификацией по PCI DSS.
С какой стороны подойти и как аргументировать?
Разбить на мелкие части и на глаз каждую?
А если какой-то из этапов подразумевает под собой какую то долю неопределенности в том, как ее разрабатывать именно?

Выручайте, мужики, очень рассчитываю на Ваш опыт!

Как вы оцениваете крупные проекты?, 4.0 out of 5 based on 1 rating
Tagged with →  

9 Responses to Как вы оцениваете крупные проекты?

  1. Pmere:

    не претендую на звание крутого проджект менеджера ибо на своих же ошибках учусь каждый день, до этого работал как рядовой и старший программист.

  2. HTnMsk:

    agile agile agile

    Подготовить верхнеуровневый план релизов проекта, работать итерационно, потому что проект за время разработки может полностью поменяться. Денег просить за выполнение обозреваемых релизов.

  3. Ngein:

    Борьба с оценкой неопределенности — как уже сказано — происходит делением большой неопределенности на много маленьких, а также гибким ценообразованием — можно попробовать убедить клиента в том, что когда неопределенностей слишком много, для достижения реального результата разумней платить не за всю никому не известную пока систему, а за потраченное на ее разработку время специалистов.

    Аргументы могут быть простые — «мы не знаем, что будет, вы не знаете, что будет; если нашей сегодняшней оценки стоимости не хватит, разработчики просто разбегутся и результата не будет никакого». Для того, чтобы у клиента не было сомнений в достоверности ваших отчетов о затраченном времени, ввести этапность работ, как сказано выше, и сдавать отчеты/получать деньги за понятные заказчику завершенные этапы.

  4. Pmere:

    о, спасибо за agile. ушел читать википедию и relative ресурсы

  5. Pmere:

    какие-то тулзы для проектирования кто-то использует может хорошие? возможно есть хорошие онлайн? azalo.net?

  6. HTnMsk:

    notepad рулит, а так же его продвинутый вариант – sublime text 2

  7. Xxxre:

    для agile – versionone отлично подходит.

  8. LesVelo:

    умные люди говорят, что самое рисковое и неопределенное делать первым. сам с таким не сталкивался.

  9. Tua00:

    Разбивай на куски, инкриментируй. Готовся к тому, что заказчик захочет по ходу изменить требования к проекту, потому что даже он не может 100% знать, что лучше в итоге.

Добавить комментарий