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