Vitaly Salakhmir
С учетом твитеровской лояльности к любому роду контента, думаю аудитория онлифанс перетечет именно сюда.
У прожекта не может быть подчиненных, это роль другого порядка. Но опять же – *в этой стране* бывает, потому что кто-нибудь по-своему понимает, кто это и зачем.
Такое есть, да. Увы.
Это зависит от того, где работает прожект и какие задачи ему поручено решать. Стандартизации фактически нет, и назвать прожектом могли хоть продавца.
Agile/Scrum :-)
Для внутренних проектов без MVP не обходимся (если это только не совсем простой проект). Скорее оно даже не MVP, но продукт, которым уже можно пользоваться – далее он развивается эволюционно.
Для клиентских проектов MVP фактически не используется – это увеличивает бюджет проекта, и этот оверкост ложится на плечи агентства, что не есть хорошо с позиции бизнеса. Были случаи, когда клиент предлагал начать с MVP – если самому клиенту нужно протестировать идею. Было такое, что MVP после тестов убивался, и боевой проект начинали делать с нуля – частный случай.
По поводу перевода людей из одного направления в другое – могу выразить субъективный взгляд, ибо на практике с таким почти не встречался, а переводить кого-то вне полномочий. "Правильный подход или он не работает?" – а как он должен работать, чего компания добивается? Того, что угадает и человек вдруг окажется крайне хорошим исполнителем в сфере, в которую его отправили на удачу? :-) Тут важны детали: если человека перекидывают из отдела в отдел, чтобы угадать, где он будет лучше работать – это так себе затея. Если человек пришел в тот же бэкэнд и не вывез, но у него хороший бэкграунд как UX (и он не против вернуться обратно), то конечно, это сработает лучше.
1. Сроки по таскам (диджитал-проекты). Если задача входит в понимание менеджера (экспертное или историческое), вычисляется менеджером. Если нет, то исполнителем. Еще имеет значение, о каком исполнителе идет речь – если программист может прикинуть сроки на основе своего исторического/экспертного опыта, то дизайнер или технолог это вряд ли сделает – слишком большой разброс решений у первого (плюс, креативный процесс) и вообще непредсказуемый объем работ у второго. Тут можно перечитать абзац, где про пальцы в небо – при любой оценке происходит попытка предсказания.
2. Запасы по срокам. Запасы закладываются всегда и во все задачи – а вот по каким принципам, на публику рассказать не могу.
3. Если не влезаем по времени. Я не знаю, о каком проекте идет речь, не знаю его содержания, потому в общем.
а) Сократить содержание проекта – идти по "критическому пути", отбрасывая несущественное. Запускаться кусками, либо по Agile – итерациями.
б) Подключить дополнительных разработчиков – там где можно работать командой.
в) Если первые два пункта не подходят, передоговариваться с заказчиком.
У нас есть ограничения: сроки/стоимость/содержание – нельзя насильно всунуть что-то одно, чтобы с другой стороны не вылезло.
4. PERT. Не пользуюсь: либо проекты недостаточно большие, либо проекты достаточно большие, чтобы было лень этим заниматься :-) Рисовать графики можно хоть ручкой на бумаге, или в том же гуглдоке ("рисунок"). Лучшее что я встречал для рисования именно PERT – сервис draw.io (выбирайте флоучарты). Сервис бесплатный.
Понятно, что ничего не понятно.