На проектах я регулярно вижу одну и ту же поломку: сроки оценивают не по составу работ, а по названию задачи.
«PDF за день» — звучит просто, пока не раскладываешь на схему:
1. модель данных и поля;
2. backend-генерация;
3. верстка шаблона под печать;
4. предпросмотр;
5. проверка качества на реальных данных;
6. правки после первого прогона.
Если нужен пиксель-перфект, таблицы, шрифты, переносы, несколько типов документов и интеграция с БД — это уже не “мелкая доработка”. На dompdf, например, любой сложный макет быстро превращается в набор компромиссов.
Мой вывод простой: плохая оценка сроков почти всегда бьет не только по разработчику, но и по качеству решения. А потом проект внезапно «не успеваем», команда живет на переработках, и крайним оказывается тот, кто честно назвал реальный объем.
В интеграциях и backend-задачах я всегда прошу сначала схему: что генерируем, где храним, кто согласует, как тестируем. Без этого оценка — гадание, а не архитектура. 😐
Битрикс Stack
@BitrixStackPro
На проектах я регулярно вижу одну и ту же поломку: сроки оценивают не по составу работ, а по названию задачи.
Этот пост опубликован в Telegram-канале Битрикс Stack. Подписаться можно по ссылке: @BitrixStackPro.