Vitaly Salakhmir
С учетом твитеровской лояльности к любому роду контента, думаю аудитория онлифанс перетечет именно сюда.
У прожекта не может быть подчиненных, это роль другого порядка. Но опять же – *в этой стране* бывает, потому что кто-нибудь по-своему понимает, кто это и зачем.
Такое есть, да. Увы.
Это зависит от того, где работает прожект и какие задачи ему поручено решать. Стандартизации фактически нет, и назвать прожектом могли хоть продавца.
Agile/Scrum :-)
Для внутренних проектов без MVP не обходимся (если это только не совсем простой проект). Скорее оно даже не MVP, но продукт, которым уже можно пользоваться – далее он развивается эволюционно.
Для клиентских проектов MVP фактически не используется – это увеличивает бюджет проекта, и этот оверкост ложится на плечи агентства, что не есть хорошо с позиции бизнеса. Были случаи, когда клиент предлагал начать с MVP – если самому клиенту нужно протестировать идею. Было такое, что MVP после тестов убивался, и боевой проект начинали делать с нуля – частный случай.
По поводу перевода людей из одного направления в другое – могу выразить субъективный взгляд, ибо на практике с таким почти не встречался, а переводить кого-то вне полномочий. "Правильный подход или он не работает?" – а как он должен работать, чего компания добивается? Того, что угадает и человек вдруг окажется крайне хорошим исполнителем в сфере, в которую его отправили на удачу? :-) Тут важны детали: если человека перекидывают из отдела в отдел, чтобы угадать, где он будет лучше работать – это так себе затея. Если человек пришел в тот же бэкэнд и не вывез, но у него хороший бэкграунд как UX (и он не против вернуться обратно), то конечно, это сработает лучше.
1. Сроки по таскам (диджитал-проекты). Если задача входит в понимание менеджера (экспертное или историческое), вычисляется менеджером. Если нет, то исполнителем. Еще имеет значение, о каком исполнителе идет речь – если программист может прикинуть сроки на основе своего исторического/экспертного опыта, то дизайнер или технолог это вряд ли сделает – слишком большой разброс решений у первого (плюс, креативный процесс) и вообще непредсказуемый объем работ у второго. Тут можно перечитать абзац, где про пальцы в небо – при любой оценке происходит попытка предсказания.
2. Запасы по срокам. Запасы закладываются всегда и во все задачи – а вот по каким принципам, на публику рассказать не могу.
3. Если не влезаем по времени. Я не знаю, о каком проекте идет речь, не знаю его содержания, потому в общем.
а) Сократить содержание проекта – идти по "критическому пути", отбрасывая несущественное. Запускаться кусками, либо по Agile – итерациями.
б) Подключить дополнительных разработчиков – там где можно работать командой.
в) Если первые два пункта не подходят, передоговариваться с заказчиком.
У нас есть ограничения: сроки/стоимость/содержание – нельзя насильно всунуть что-то одно, чтобы с другой стороны не вылезло.
4. PERT. Не пользуюсь: либо проекты недостаточно большие, либо проекты достаточно большие, чтобы было лень этим заниматься :-) Рисовать графики можно хоть ручкой на бумаге, или в том же гуглдоке ("рисунок"). Лучшее что я встречал для рисования именно PERT – сервис draw.io (выбирайте флоучарты). Сервис бесплатный.
В какой сфере вы его планируете использовать? Инструменты – под составление?
Спасибо :-)
Действительно, прошло 8 месяцев с момента, когда решил, что надо такое намутить до момента, когда сел за первую статью.
Будет в одной из частей, отдельная тема.
Это серия. Сначала азы, потом внутрь - разберемся с теорией, полезем в дебри :-)
Главное, чтобы было построено на логике, какого пола эта логика - вопрос второй :-)
Модульный подход нужен оттого, что блоки и части проще контролировать.
А то, что проекты сворачивают не проблемы управления проектами. Вот насчёт "вовремя" - оно да, есть такая проблема.
Два часа ушло на новую статью: https://vc.ru/39800-metodologii-upravleniya-proektami-vodopad-edzhayl
Судя по тенденции выхода моих записей – следующая статья будет примерно в ноябре :-) Следующая статья будет про методологии управления – постараюсь рассказать на пересечении с практикой.
Спасибо за комментарии :-)
Здесь самый первый уровень предмета - он должен помочь с пониманием самых основ, и его аудитория - не профи. Планирую серию статей, с нарастающим уровнем сложности.
PMBoK - прозрачный свод правил. Оттуда растет Agile и Waterfall - то, как скорее всего работает менеджер на постсоветском пространстве. Про PRINCE2 и MSF тоже, вероятно, поговорим.
Я думал, подпись в крупных компаниях описывает корпоративная этика. Подпись через почтовый сервер – это сильно, буду иметь ввиду.
Не придумывает же подпись за вас, вставляет ранее заданную.
Тут в значении, если действительно говорил с человеком по телефону – для напоминания и закрепления результатов разговора. Почему нет?
Как работают подписи в почтовых программах? :-)
Понятно, что ничего не понятно.