правила управления софтверно-дизайнерской шарашкой
От: rsdn131113  
Дата: 15.11.13 22:18
Оценка: 4 (1)
я немного подумал, вспомнил и суммировал в едином списке правила управления софтверно-дизайнерской географическо-распределенной "шарашкой" по результатам многолетнего опыта работы в таких и наблюдения со стороны и не совсем со стороны всех проблем в которые вляпывается народ

может кто расширит список?

общие правила:
— если клиента напрягает наличие в контракте пунктов по ограничению ответственности, ограничение гарантии и невозмещении ущерба, то предложить клиенту оценить сумму, которую он хотелд бы с меня стрясти в случае чего, и добавить к стоимости проекта стоимость бизнес страховки с покрытием на эту сумму; если клиент напрягается и на этот счет, отправлять клиента в далекое путешествие в сказочные страны
— не брать проекты длительностью более 6 месяцев, поскольку я даже сам собою более длительный срок управлять не могу, а не то что группой "мегатворческих" девелоперов-дизайнеров из разных стран (если уж совсем хочется большой проект, то разбить на 6месячные итерации и начало второй итерации сразу обговорить на неизвестный срок в будущем)
— стандартизация и документация всего и для всех обязательны
— юридическую и бухгалтерскую документацию перепроверять по 10 раз самому
— держать дистанцию между собой, клиентами и работниками (не переходить на личные отношения любого рода)
— сроки названные исполнителями при передаче клиенту увеличивать в 1.5-3 раза
— контроль версий всего (включая деловую документацию), оффлайн бэкапирование всего в банковский сейф

правила для софтверных проектов
— контролировать процесс разработки через обязательное рисование схем бд, диаграмм взаимодействий классов/модулей/методов в сложных классах, а также взаимный и не взаимный code review
— плагинную архитектуру разрабатывать с самого нала проекта (это позволит сразу же подключить на проект большое количество миддлов и джуниоров на коротких, и даже и на коротких part-time контрактах)
— стрессовое тестирование вести с самого начала проекта
— на написание ядра многомесячного проекта сразу брать минимум 2х людей иначе замена одного потом влетит в бешеные деньги
— так сказать стандартные технические интервью, это лишь метод политкорректной фильтрации кандидатов (даже гугл это уже признал в открытую)
— учитывая взятый лимит сроков, то для управления проектом достаточно будет инструмента для подсчета времени и внутреннего форума со списками задач по категориям в стиле basecamp (все методологии и прочие тулзы идут лесом)
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.