Здравствуйте, rsdn131113, Вы писали:
R>я немного подумал, вспомнил и суммировал в едином списке правила управления софтверно-дизайнерской географическо-распределенной "шарашкой" по результатам многолетнего опыта работы в таких и наблюдения со стороны и не совсем со стороны всех проблем в которые вляпывается народ
R>может кто расширит список?
Какие-то стремные у тебя правила.
R>общие правила: R>- если клиента напрягает наличие в контракте пунктов по ограничению ответственности, ограничение гарантии и невозмещении ущерба, то предложить клиенту оценить сумму, которую он хотелд бы с меня стрясти в случае чего, и добавить к стоимости проекта стоимость бизнес страховки с покрытием на эту сумму; если клиент напрягается и на этот счет, отправлять клиента в далекое путешествие в сказочные страны
Ответственность по договору должна быть ограничена, да.
R>- не брать проекты длительностью более 6 месяцев, поскольку я даже сам собою более длительный срок управлять не могу, а не то что группой "мегатворческих" девелоперов-дизайнеров из разных стран (если уж совсем хочется большой проект, то разбить на 6месячные итерации и начало второй итерации сразу обговорить на неизвестный срок в будущем)
Брать, но только по time & material. Впрочем, по fixed price среднестатистическая шарашка все равно такие проекты не потянет.
R>- стандартизация и документация всего и для всех обязательны
Буллшит. Пока ты мелкий выгоднее хранить знания в головах, а не на бумаге.
R>- юридическую и бухгалтерскую документацию перепроверять по 10 раз самому
Отдать на ацтсорсинг и прописать ответственность в договоре.
R>- держать дистанцию между собой, клиентами и работниками (не переходить на личные отношения любого рода)
Буллшит. Личные отношения крайне полезны. Был на заре моей карьеры такой случай: в конторе образовался кассовый разрыв, бывает такое. Владелец пришел к сотрудникам и сказал: "Ребята, фигня случилась, зарплата задерживается. Давайте я как бы займу у вас эти деньги под ставку рефинансирования, а отдам как рассосется." И два месяца он рассчитывался с сотрудниками в основном расписками. Потом дела наладились и расписки были обналичены. Ни будь у него личных отношений с сотрудниками, его бы просто послали на йух и никакого бизнеса бы больше не было.
Аналогично, приходилось получать заказы от друзей, которые говорили: "Ценник у тебя, конечно, конский, но я тебя знаю и верю что ты не подведешь"
R>- сроки названные исполнителями при передаче клиенту увеличивать в 1.5-3 раза
Буллшит. Нужно использовать современные методики оценки и планирования, а не гадать на кофейной гуще. Тем более что если проект на 3 месяца, а вы выкатите заказчику срок в 9 месяцев, но просто не станет с вами работать.
R>- контроль версий всего (включая деловую документацию), оффлайн бэкапирование всего в банковский сейф
Это обязательно, как и бэкап себе домой и на независимый сервер. Бэкапы обязательно шифровать. Раз в год устраивать тренинг по развертыванию всего из бэкапов.
R>правила для софтверных проектов R>- контролировать процесс разработки через обязательное рисование схем бд, диаграмм взаимодействий классов/модулей/методов в сложных классах, а также взаимный и не взаимный code review
Буллшит. Контролировать процесс разработки имеет смысл только через функциональные требования. Лезть самому в классы это микроменеджмент, который еще никого до добра не доводил.
R>- плагинную архитектуру разрабатывать с самого нала проекта (это позволит сразу же подключить на проект большое количество миддлов и джуниоров на коротких, и даже и на коротких part-time контрактах)
Не обязательно плагинную, просто разделение на ядро и мясо.
R>- стрессовое тестирование вести с самого начала проекта
Бесполезно. Стрессовое тестирование можно нормально провести только получив с реальной системы профиль нагрузки. Иначе твои тестеры протестируют то что проще, а система после релиза встанет.
R>- на написание ядра многомесячного проекта сразу брать минимум 2х людей иначе замена одного потом влетит в бешеные деньги
Если замена одного влетает в бешеные деньги, значит ты ему крепко недоплачиваешь. Опять же, если ты так делаешь следи чтобы эти двое не договорились.
R>- так сказать стандартные технические интервью, это лишь метод политкорректной фильтрации кандидатов (даже гугл это уже признал в открытую)
В маленькой конторе психологическая совместимость роляет больше чем профессиональные навыки. Толку от классного спеца немного, если он со всеми посрался. Поэтому для найма лучше всего привлекать профессиональных хедхантеров у которых есть психологическое образование и опыт в IT. Как правило они дают гарантию на свою работу.
Еще про найм: никогда никого не брать по знакомству или по рекомендациям.
R>- учитывая взятый лимит сроков, то для управления проектом достаточно будет инструмента для подсчета времени и внутреннего форума со списками задач по категориям в стиле basecamp (все методологии и прочие тулзы идут лесом)
Методологии нужны чтобы закладывать +30% к срокам, а не +300% как у тебя. Тулзы нужны чтобы не делать руками, например чтобы не держать список задач в голове.
R>а вот кое какие правила для управления дизайнерскими проектами R>- дизайнерский проект в мелких студиях с уклоном в полиграфию и веб в среднем занимает 2 недели и делается 1-3 людьми
Где-то так, да.
R>- прежде чем брать проекты нужно иметь 2 базы исполнителей — для основной работы из N человек, для быстрого исправления-доработки из N*2 человек, на случай если человек из первой базы ушел в творческую депрессию за неделю до окончания (а прочие люди из группы N брезгуют заниматься подчистками и доработками из "религиозных" соображений)
Разумно.
R>- дизайнерам платить мало и в среднем по рынку, разжиревший дизайнер имеет тененцию открывать свою студию и выходить в свободное плавание (чтобы не мучила совесть, смотрите пункт о недопустимости личных отношений)
Если у вас нормальные отношения, дизайнера, а скорее даже арт-директора, нужно брать в долю. Опять же при хороших отношениях бывшие сотрудники ушедшие в собственный бизнес это ценный ресурс. Можно скидывать им заказы, одалживать у них исполнителей; они будут скидывать заказы тебе.
R>- прибыль в дизайне для директора делается исключительно за счет хороших отношений с клиентом и знания предметной области, если дизайн узкоспециализированный ( в последнем случае вместо узкоспециализированного дизайнера работает связка вы плюс дизайнер широкого профиля)
Прибыль в дизайне делается за счет раскрученного имени дизайнера поэтому на саморекламе экономить ни в коем случае нельзя.
R>- дизайн — это мода и эргономика, а не искусство (в широком смысле всех слов), и таким образом, если вы концентрируетесь на моде, а не эргономике, чтобы отсеивать шлак от качественных работ нужно быть самому зажравшимся бытовым массовым визуальным мусором и постоянно бывать в центрах мировой моды (европа, северная америка), и если у вас нет денег на такую жизнь, то и не думайте о работе в этой роли исключительно на ролях директора
Делать дизайн на основании моды это означает плестись в хвосте индустрии в толпе таких же посредственностей. Чтобы раскрутиться как дизайнеру, нужно упирать либо на качество (например, внимание к мелочам) либо на технологию (которую большинство дизайнеров будучи гуманитариями осваивают с большим опозданием). Ну и да, вкус нужен, но для этого совершенно не обязательно куда-то ехать. Можно обойтись интернетом.
