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

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

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

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

а вот кое какие правила для управления дизайнерскими проектами
— дизайнерский проект в мелких студиях с уклоном в полиграфию и веб в среднем занимает 2 недели и делается 1-3 людьми
— прежде чем брать проекты нужно иметь 2 базы исполнителей — для основной работы из N человек, для быстрого исправления-доработки из N*2 человек, на случай если человек из первой базы ушел в творческую депрессию за неделю до окончания (а прочие люди из группы N брезгуют заниматься подчистками и доработками из "религиозных" соображений)
— дизайнерам платить мало и в среднем по рынку, разжиревший дизайнер имеет тененцию открывать свою студию и выходить в свободное плавание (чтобы не мучила совесть, смотрите пункт о недопустимости личных отношений)
— прибыль в дизайне для директора делается исключительно за счет хороших отношений с клиентом и знания предметной области, если дизайн узкоспециализированный ( в последнем случае вместо узкоспециализированного дизайнера работает связка вы плюс дизайнер широкого профиля)
— дизайн — это мода и эргономика, а не искусство (в широком смысле всех слов), и таким образом, если вы концентрируетесь на моде, а не эргономике, чтобы отсеивать шлак от качественных работ нужно быть самому зажравшимся бытовым массовым визуальным мусором и постоянно бывать в центрах мировой моды (европа, северная америка), и если у вас нет денег на такую жизнь, то и не думайте о работе в этой роли исключительно на ролях директора

Здравствуйте, rsdn131113, Вы писали:

R>а вот кое какие правила для управления дизайнерскими проектами
R>- дизайнерский проект в мелких студиях с уклоном в полиграфию и веб в среднем занимает 2 недели и делается 1-3 людьми
R>- прежде чем брать проекты нужно иметь 2 базы исполнителей — для основной работы из N человек, для быстрого исправления-доработки из N*2 человек, на случай если человек из первой базы ушел в творческую депрессию за неделю до окончания (а прочие люди из группы N брезгуют заниматься подчистками и доработками из "религиозных" соображений)
R>- дизайнерам платить мало и в среднем по рынку, разжиревший дизайнер имеет тененцию открывать свою студию и выходить в свободное плавание (чтобы не мучила совесть, смотрите пункт о недопустимости личных отношений)
R>- прибыль в дизайне для директора делается исключительно за счет хороших отношений с клиентом и знания предметной области, если дизайн узкоспециализированный ( в последнем случае вместо узкоспециализированного дизайнера работает связка вы плюс дизайнер широкого профиля)
R>- дизайн — это мода и эргономика, а не искусство (в широком смысле всех слов), и таким образом, если вы концентрируетесь на моде, а не эргономике, чтобы отсеивать шлак от качественных работ нужно быть самому зажравшимся бытовым массовым визуальным мусором и постоянно бывать в центрах мировой моды (европа, северная америка), и если у вас нет денег на такую жизнь, то и не думайте о работе в этой роли исключительно на ролях директора

Какого размера организации вы описываете? Сколько каких спецалистов в штате?
Какого типа софтварные продукты занимают разработку всего 6 месяцев?
Неужели на рынке еще есть место для студий клепающих сайты, мне кажется там уже дишать нечем, хотя соглашусь, что большая часть из наверно полное гавно, в виде двух человек берущих за сайт 100-150 тыс. рублей и раскидывающих работу на фрилансеров.

Здравствуйте, rsdn131113, Вы писали:

R>- плагинную архитектуру разрабатывать с самого нала проекта (это позволит сразу же подключить на проект большое количество миддлов и джуниоров на коротких, и даже и на коротких part-time контрактах)

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

Здравствуйте, Grayscaler, Вы писали:

G>Здравствуйте, rsdn131113, Вы писали:

R>>- плагинную архитектуру разрабатывать с самого нала проекта (это позволит сразу же подключить на проект большое количество миддлов и джуниоров на коротких, и даже и на коротких part-time контрактах)

G>Вот это не понял. Хорошая архитектура и без плагинов позволяет подключать кого угодно на любых сроках.

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

A>Какого размера организации вы описываете? Сколько каких спецалистов в штате?
A>Какого типа софтварные продукты занимают разработку всего 6 месяцев?
A>Неужели на рынке еще есть место для студий клепающих сайты, мне кажется там уже дишать нечем, хотя соглашусь, что большая часть из наверно полное гавно, в виде двух человек берущих за сайт 100-150 тыс. рублей и раскидывающих работу на фрилансеров.

если говорить о софтверных проектах, то до 20 девелоперов + 10 человек на бизнес-персонал и креаторский персонал + 5 человек на менеджмент и всякий узкоспециализированный консалтинг по предметной области = итого 25
такими силами можно покрыть достаточно большой диапазон проектов

Здравствуйте, Grayscaler, Вы писали:

G>Здравствуйте, rsdn131113, Вы писали:

R>>- плагинную архитектуру разрабатывать с самого нала проекта (это позволит сразу же подключить на проект большое количество миддлов и джуниоров на коротких, и даже и на коротких part-time контрактах)

G>Вот это не понял. Хорошая архитектура и без плагинов позволяет подключать кого угодно на любых сроках.

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

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

и поэтому им надо выдавать так сказать "изолированные" задачи плагинного типа не требующие погружения вглубь

Здравствуйте, rsdn131113, Вы писали:

R>если говорить о софтверных проектах, то до 20 девелоперов + 10 человек на бизнес-персонал и креаторский персонал + 5 человек на менеджмент и всякий узкоспециализированный консалтинг по предметной области = итого 25
R>такими силами можно покрыть достаточно большой диапазон проектов

опечатка = итого 35

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

— Не идти на поводу у заказчика. Помнится взяли проект для Чикаго, договорилсь на сумму. Сделали — оплатил.
Но потом попросил доделать за маленькую сумму доделки и целый месяц угрохали на это, проработав бесплатно.
Но я не в обиде — купил хороший диван (Белоруского производства) за 55т. Теперь люблю на нем отдыхать и смотреть телевизор.

А вы кстати открываться собираетесь или уже давно открылись, но хотите формализовать где то имеющийся опыт?

Здравствуйте, 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>- дизайн — это мода и эргономика, а не искусство (в широком смысле всех слов), и таким образом, если вы концентрируетесь на моде, а не эргономике, чтобы отсеивать шлак от качественных работ нужно быть самому зажравшимся бытовым массовым визуальным мусором и постоянно бывать в центрах мировой моды (европа, северная америка), и если у вас нет денег на такую жизнь, то и не думайте о работе в этой роли исключительно на ролях директора

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

Здравствуйте, Alllie, Вы писали:

A>А вы кстати открываться собираетесь или уже давно открылись, но хотите формализовать где то имеющийся опыт?

я пока так, обдумываю жизненный опыт

просто почуствовал, что наконец-то дошел до той цели с которой изначально пошел в айти в качестве наемника — а именно, полное понимание "ремесленной" части процесса и типичных бизнес-ошибок на чужом примере

если откроюсь и обнаружится что-то еще интересное в процессе, то обязательно напишу

R>>- стандартизация и документация всего и для всех обязательны
S>Буллшит. Пока ты мелкий выгоднее хранить знания в головах, а не на бумаге.

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

либо просто не надоело все

R>>- юридическую и бухгалтерскую документацию перепроверять по 10 раз самому
S>Отдать на ацтсорсинг и прописать ответственность в договоре.

разве станет юрист или бухгалтер всерьез (даже еслитак написано в договоре) брать на себя риски 10-100-кратно превышающие гонорар?
не думаю


R>>правила для софтверных проектов
R>>- контролировать процесс разработки через обязательное рисование схем бд, диаграмм взаимодействий классов/модулей/методов в сложных классах, а также взаимный и не взаимный code review

S>Буллшит. Контролировать процесс разработки имеет смысл только через функциональные требования. Лезть самому в классы это микроменеджмент, который еще никого до добра не доводил.

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

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

Здравствуйте, rsdn131113, Вы писали:

R>Здравствуйте, Alllie, Вы писали:

A>>А вы кстати открываться собираетесь или уже давно открылись, но хотите формализовать где то имеющийся опыт?

R>я пока так, обдумываю жизненный опыт

R>просто почуствовал, что наконец-то дошел до той цели с которой изначально пошел в айти в качестве наемника — а именно, полное понимание "ремесленной" части процесса и типичных бизнес-ошибок на чужом примере

R>если откроюсь и обнаружится что-то еще интересное в процессе, то обязательно напишу

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

Немного не понятно, что вы хотите открыть.
Неужели вы планируете открыть фирму на 35 человек? Откуда столько денег?
Даже если на 5 человек, опять же откуда столько денег? Точнее есть ли такие деньги?

И еще самое главное есть ли на данный момент база клиентов?

18.11.2013 19:53, rsdn131113 пишет:

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

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

--
WBR,
Serge.

P.S. Вы видимо ещё не вполне представляете с какой скоростью
ИТ-специалисты потребляют бабло )

Здравствуйте, Alllie, Вы писали:

R>>если откроюсь и обнаружится что-то еще интересное в процессе, то обязательно напишу

A>Пишите, а лучше пишите пока думаете открыться, открываетесь, начинаете работать и т.д., интересно будет и нам и вам потом.

A>Немного не понятно, что вы хотите открыть.
A>Неужели вы планируете открыть фирму на 35 человек? Откуда столько денег?
A>Даже если на 5 человек, опять же откуда столько денег? Точнее есть ли такие деньги?

A>И еще самое главное есть ли на данный момент база клиентов?


под 35 имеется в виду максимальный размер, который я по текущему уровню подготовки скорее всего смогу вытянуть для полугодичного проекта (по собственным ощущениям) — с другой стороны более крупные проекты я на текущем этапе найти не смогу в принципе, поскольку даже в качестве исполнителя в них не работал

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

Здравствуйте, hrensgory, Вы писали:

H>18.11.2013 19:53, rsdn131113 пишет:

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

H>... во время первоначального проектирования приложения и давно не
H>имеющей ничего общего с тем, что там реально внутри находится.

именно поэтому ее нужно обновлять раз в месяц и каждый раз это должен делать кто-то, кто еще этой диаграммой не занимался

H>P.S. Вы видимо ещё не вполне представляете с какой скоростью
H>ИТ-специалисты потребляют бабло )

очень хорошо представляю!

Здравствуйте, rsdn131113, Вы писали:

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

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

R>либо просто не надоело все

Это да, но личные отношения тут как раз рулят.

R>разве станет юрист или бухгалтер всерьез (даже еслитак написано в договоре) брать на себя риски 10-100-кратно превышающие гонорар?
R>не думаю

Насчет юристов не уверен, а у аутсорсинговых бухгалтеров в договоре стандартный пункт что все проблемы с налоговой бухгалтерия берет на себя. И они реально это делают, подают на налоговую и ПФР в суд, оспаривают штрафы, а если что-то произошло по их вине оплачивают из своего кармана. Но это большая редкость.

R>как раз наоборот
R>если раз в месяц вместо копания в классах можно будет потратить полчаса-час на осмотр диаграммы их взаимодействия, нарисованной кем-то из главных разработчиков, то это самый простой вариант отслеживания технической стороны процесса

R>по моему опыту наличие таких диаграм только плюс для быстрого понимания что происходит внутри проекта

И что тебе эта диаграмма даст? Как ты по ней поймешь что уже сделано, что осталось сделать и где могут возникнуть проблемы?

Здравствуйте, smallpoxlet, Вы писали:

S>Здравствуйте, rsdn131113, Вы писали:

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

S>Распределяй знания по нескольким головам, делов-то. Тем более что я никогда не слышал чтобы кто-то их программистов вот так прямо начал работодателя открыто шантажировать.

я сам так делал неоднократно
правда я плохой человек без совести?
наверное, мне прямая дорога в бизнесмены


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

такая диаграмма дает следующее
1. сокращает время необходимое для понимания взаимосвязей в проекте
2. если где-то есть избыточные связи, или какой-то класс находится не на том уровне где надо — это мгновенно становится видно, и значит можно спланировать рефакторинг
3. если проект все таки зашел в технический тупик, и сделано много, но трудно понять что именно, а видимого функционала маловато, то такая диаграмма позволит немного снизить напряженность в отношениях с клиентами, исполнителями и менеджерами далеки от технической части, показав визуально осязаемый результат и дав передышку за которую можно доработать видимый функционал