Управлять проектом — значит каждый день что-то решать и здесь, как на минном поле, один шаг, и все взорвётся. Но на чём обычно все валятся? Люди? Подход? Сроки? Технологии? За себя могу сказать, что моей самой главной ошибкой было не слушать (или не слушаться) интуицию. Есть даже история на эту тему.
Приехало к нам ТЗ на доработку Битрикс24. Вроде ничего сверхъестественного, но куча пустой мелочевки: сделать фильтр, тут пару полей создать, здесь кнопку влепить. И такого добра пунктов на 15! Попытались обсудить это сначала один раз, потом второй, параллельно утопая в деталях и нюансах. На этом этапе интуиция подала первый звоночек, что нужно отказываться от такого «счастья». Но кто бы её послушал?
Договорились из 15 пунктов взять 3, быстро обсудить, запаковать в техзадание и реализовать. А остальное позже. Дело пошло сильно бодрее.
Заказчик присылает договор с #многабукв , где между строк можно увидеть скрытый смысл: «даже если вы все сделаете, мы найдем способ не платить, ну, или повод вернуть деньги!». Это был второй звоночек. Но коней на переправе не меняют, поэтому идём дальше. Правим договор, вводим зеркальные штрафы и убираем скользкие формулировки. Подписываем.
Дальше не сильно интересная часть по разработке. А вот после нее — этапы приёма и тестирования, на которых выяснилось, что представления Заказчика о том, как это должно работать, расходятся с тем, что он согласовал на уровне ТЗ . Встреч было штук 8, наверное, и вопросы, вроде, по делу, но все с уклоном на испытание прочности из разряда «а вот если я 44 раза за секунду нажму кнопку, то все виснет». Сдали, рассчитались, закрыли доки, залили исходники на GitHub. Можно выдохнуть.
Через 4 месяца поступает звонок:
— Давайте продолжать, — говорит Закачик.
— Спасибо, но сильно заняты, — отвечаем мы.
— Как заняты? У нас же еще осталась работа!
И, кажется, наш деловой товарищ обиделся.
Через неделю приходит письмо, в котором говорится: «Ничего не работает, а у нас прописана гарантия». Окей, раз прописана, то посмотрим. И конечно, оказалось, что всё работает так, как работало изначально.
Еще через две недели мы получили досудебную претензию с содержанием: «Если не исправите, найдем на стороне и отсудим деньги». Мы же про себя подумали «Без проблем, если так хочется, то ищите и судитесь».
Через 3 месяца прилетает вторая претензия с описанием работ и ценами. НО! Повезло, что в описании работ был хорошо прописан состав услуг, включая ряд параметров кода, которые правил новый подрядчик. Анализ нашего кода показал, что изначально эти параметры не были затронуты. Это, собственно, и спасло от суда.
Так что теперь, когда чувствую, что хочется свалить еще до начала проекта, понимаю, что это не слабость, а интуиция.
Пишу про ИТ, людей, процессы, неопределенность и про себя в Telegram. В общем, самые умные мысли там https://t. me/vroderabotaetno
