ух ты, правила появились

да, я попросил

теперь при тезисе "м1 - херня" я смогу спокойно забанить, т.к. это против правил 🙂

как будто ты раньше не мог

какая странная гифка. фэйссвап что ли

да, с моим лицом

оригинал

вооо

сам сделал? я думал бота такого написать

потер, чот много места занимают )

reface приложение

ё. ))

Что есть хорошее для записи митингов на макос? Кроме screenflow, там потом конвертить надо

quicktime?

Из ультимативных решений - OBS

1) Страховка. Если проект fix-price/waterfall, то стараться не работать по ТЗ. Вернее как: не делать приемку работ по ТЗ, потому что его можно повернуть как угодно и ТЗ, к которому нельзя придраться, не существует. ТЗ — это вектор куда мы двигаемся, но приемка работ должна быть по тест-кейсам прямо в договоре, типа таких: «открыл страницу логина -> нажал восстановить пароль -> ввел адрес электронной почты -> нажал кнопку -> пришло письмо». Эти тест-кейсы всё равно надо прописывать, всё равно они должны быть заложены еще на этапе проектирования. Кейсов может быть 100-200-300 штук, сколько угодно и какой угодно глубины в меру безумия и доверия между сторонами ;) Но разработку без них начинать нельзя. Можно сделать два договора: проектирование и разработка после проектирования. Заказчики охотно на это идут, тк ты говоришь, что после проектирования не обязательно даже выбирать нас повторно на разработку.

2) Разработка. Менеджер на таких (fix-price) проектах обязательно свой, а не клиента. Тестировщик тоже. Полная прозрачность: всегда письма с итогами после всех звонков и совещаний, фиксация договоренностей. Немедленное озвучивание всех рисков: от проблем на третьей стороне до заболевшего твоего разработчика. Но важно делать это для проекта, а не для заказчика. Малоопытные всегда стараются подсветить косяки заказчика и скрыть свои — это большая ошибка. Надо действовать беспристрастно по отношению к проекту. Заказчик может быть полным говном в процессе, но если не смотря на это ты покажешь результат, то он станет твоим лучшим партнером. К сожалению, в РФ часто такая ментальность. Опять-же, не всем это подходит, но у меня был такой опыт. Закаляет :)

3) Если назрел конфликт, то можно решать по-разному. Тут уже искусство переговоров и прозрачность из п2 сильно поможет. Заказчику тоже часто не выгодно дергать стоп-кран. Но при этом многие готовы обсуждать цвет кнопки часами (реальный случай в проекте: несколько раз встречались впятером с топ-менеджментом, чтобы обсудить как поступим с 7 мелкими задачами). Проект — как военный фронт: он не прямая линия. Есть котлы и другие изгибы. И всегда есть твое преимущество в том, что ты произвел код, за который заказчик не заплатил (РИД). И есть преимущество заказчика в том, где ты не преуспел. Садитесь и обсуждаете. И отдать X денег за экономию твоего личного времени на весь этот буллшит иногда не самая плохая идея ;)

Конечно, многое из упомянутого не относится к проектам T&M, за что я их нежно люблю.

Илья, спасибо огромное, что изложил так четко и ясно! Я под всем подписываюсь, прям будто витали уже в подсознании, но не было сформулировано.

И есть вопросы у меня:

Скажи пожалуйста, этап проектирования — это как раз прописывание кейсов или что-то другое?

#fomo

Ты это, предупреждаешь хоть, или расстрел и есть предупреждение?