Как стать автором
Обновить

Комментарии 10

- как ему проверить подозрения, чтобы снять например параною

Мне кажется, тут важно проектное планирование вкупе с продуманным ТЗ. Проект разбивается на древовидную структуру задач или требуемых фич (каждому узлу дерева назначаем дэдлайн и исполнителя - человека или подразделение, всё как в программах управления проектами типа Planner, kPlato, MS Project). Неким образом демонстрируем дерево заказчику. По ходу дела отмечаем выполненные фичи/задачи, опять демонстрируя дерево заказчику. В договоре прописаны штрафы за нарушение дэдлайнов. Если всё сделать дотошно (и объяснить заку и программерам сначала весь процесс), волки будут сыты, а овцы - целы.

Это некая идея только, как конкретно это делать - не знаю.
Сторонние аудиты не нравятся никому.

Проверяйте ИСХОДНЫЕ материалы (ТЗ, материалы для публикаций, данные, изображения, дизайны) ДО того как разработчик их использует - если вы это сделаете после, слишком велика вероятность, что придется всё переделывать. Туманно как-то сказал. Например, дизайнер нарисовал дизайн. Без критики арт-директора, юзабилити-спеца и верстальщика этот дизайн не принимается, как бы красив он ни был.
Расскажите как, мне организовать технически проверку, изменения в части классов, java сервера, до их применения, и как оценить, норму затрат времени на исправление, найденной мной ошибки?
Диагностировать не-спецу реальные сложности и саботаж проекта по моему почти невозможно.

Хороший ход, кстати - сначала писать документацию. Совместно. И вообще, «всякое дело делается два раза - на стадии проектирования и на стадии выполнения». Проект должен быть рабочей моделью того, что вы хотите сделать. Без белых пятен, без «потом додумаем». Если в чем то сомневаетесь - не делайте этой фичи пока. Продумаете - сделайте.
К сожалению, в моем случае, програмисты, верят, или говорят что верят, в то что - документирование проекта - не нужна, нет смысла ее делать и они этим заниматься не будут.
Ох, худо-то... Религия - дело личное, вам-то что с того, во что они верят? Вы заказчик. В договоре, конечно, стоило прописать... Ох, тяжкая ситуевина.
Представьте печальную, ситуацию, заказчик немного понимает, в процессе, и еще и ухитряеться лично найти например ошибки в описании классов, и т.д. Что ему делать дальше, кроме, как полностью сменить состав, а в случае если часть програмеров партнеры?

Я скорее про это, не про то как понять, что вообще происходит, mfpjdst методы управления проектами, я боле менее себе представляю...
Мммх... Сложная ситуевина. Извините, что сразу не врубился... Это уже сейчас, или только опасения? Состав полностью менять - очень нехорошо... Может, раз сами соображаете, ввести-таки аудит кода. Неплохая будет идея. Если это в договоре прописать - тестирование и аудит. Бабос уходит после прохождения и того, и другого. Программинг, блин, штука такая, со стандартами проблемы... К несчастью, сам я специализируюсь в несколько другой области разработки, вы меня-то не слушайте особо, я вам тут насоветую щас...
к сожалению, у меня самого нет времени, на полный аудит кода, это уже сейчас, ситауция совсем сложная, и стоила она мне уже прилично :) вот и ищу кто как с этим разбирается, может есть кто занимается, аудитом....

И еще просморел профиль, честно говоря, так не понял, чем занимаетесь, если не сложно скажите, у меня не единственный проект с проблеммами :) не только джава :)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.