Список дефектів на будівельному об'єкті: як його вести, щоб не сперечатися при прийманні
Здача призначена на четвер. У середу ввечері хтось питає в груповому чаті «а та тріщина біля колони на четвертому - її виправили», і далі півгодини шукають, хто її сфотографував, коли, і чи взагалі про неї казали субпідряднику.
Це і є дорогий момент. Не сама тріщина - вона на півдня роботи. Дорого коштує те, що ніхто не може довести, коли її помітили, кому доручили і чи прийняли. У суперечці виграє той, у кого є дати і фото. При нічиїй платить власник об'єкта.
Що насправді ламається
Список дефектів рідко провалюється тому, що хтось не знає, що треба виправити. Він провалюється у трьох місцях:
Немає автора і дати. «Я йому казав» - це не запис. Через два тижні обидві сторони пам'ятають по-різному.
Немає терміну. Дефект без кінцевого терміну - це не завдання, а побажання. Ніхто не скаже, чи він запізнюється.
Немає доказу. Фото, зроблене на місці в момент виявлення, вартує більше, ніж три сторінки опису. Якщо його немає, суперечка - це слово проти слова.
Далі показую, який вигляд має ведення такого списку в Construction Team. Демо нижче проходить через усе життя одного дефекту і крутиться саме.
Дефектні відомості
Будмайданчик / Дефекти
Відкриті
2
У роботі
1
На перевірку
1
Закриті
2
Прострочені
2
Усі дефекти на всіх ваших об’єктах в одному місці: хто що має усунути, до якого терміну і які строки вже прострочені. Червоний колір - це не декор: це ті два прострочені пункти, які враховано в картці вище.
Як це ведеться
Кожен дефект - окремий запис із номером. Номер складається сам із коду об'єкта - для об'єкта з кодом LOZ дефекти йдуть DEFLOZ-001, DEFLOZ-002 і так далі. Це означає, що номер можна написати прямо на місці, крейдою на самій стіні, а потім знайти його в списку.
Обов'язкові лише два поля: «Проект» і «Назва». Решта - «Місце», «Відповідальний», «Підрядник (субпідрядник)», «Кінцевий термін», «Категорія» - заповнюється, якщо відома. Дефект, заведений нашвидкуруч із двома полями, корисніший за дефект, який не завели, бо не було часу на повну форму.
Фото йдуть із телефона просто на місці. Вони завантажуються на сервер після того, як запис уже створено, тобто не треба чекати на зв'язок, щоб завершити обхід.
Статусів п'ять, і переходи між ними обмежені. Відкритий, У роботі, На перевірку, Закритий, Відхилений. Система не дозволяє довільного руху: зі статусу «На перевірку» є лише два виходи - прийняти або повернути на доопрацювання. Це не обмеження заради обмеження, а спосіб не закрити дефект, на який ніхто не подивився.
Прострочений - це той, у якого термін минув, а він ще не закритий і не відхилений. Прийнятий дефект перестає рахуватися простроченим, хоча дата та сама. Щоранку о сьомій йде нагадування про терміни, які наближаються або вже минули - на скільки днів наперед дивитися, налаштовується.
Три речі, які вирішують суперечку
Якщо звести до найголовнішого, ведений список дає три записи, яких папір і чат не дають.
Номер і дата заведення. Показують, коли проблему помітили, а не коли хтось згадав про неї сказати.
Фото з того моменту. Прикріплене до запису, а не надіслане в чат і загублене серед чотирьохсот інших повідомлень.
Хто прийняв і коли. Хронологія зберігає, хто створив запис, момент позначення «Готовий до перевірки», момент закриття та ім'я в полі «Перевірив». Це той рядок, який у суперечці говорить замість вас, і саме тому приймання - окрема дія від усунення.
До цього додається «Вплив на вартість» - поле, у яке записують, скільки коштує усунення. Воно не обов'язкове, але коли заповнене, розмова із субпідрядником про утримання стає розмовою про цифри, а не про відчуття.
Чого воно не робить
Немає імпорту з файлу. Дефекти заводяться в системі. Експорт є - в Excel, CSV або PDF, для протоколу чи для надсилання - а зворотного напрямку немає. Старий список у таблиці переноситься вручну.
Не замінює протокол приймання. Список - це робочий інструмент, який веде до протоколу, а не сам протокол.
Не вирішує, хто винен. Він записує, хто що сказав і коли. Відповідальність залишається розмовою між людьми, тільки розмовою з датами.
Коротко
Список дефектів ведеться добре тоді, коли заведення запису забирає менше часу, ніж суперечка, якій воно запобігає. Тому два обов'язкові поля, номер, який складається сам, і фото з телефона роблять більше роботи, ніж детальна форма, яку ніхто не заповнює на об'єкті.
А при здачі в четвер зранку відповідь на «ту тріщину виправили» - це один екран, а не півгодини копирсання.
Часті запитання
Коли дефект заводять записом, а коли просто кажуть майстрові?
Якщо усунення залежить від іншої людини або від іншої фірми - заводять. Сказане вголос не має дати, не має автора і його ніяк не перевірити через два тижні. Дрібниці, які виправляються на місці за хвилину, запису не варті.
Хто має закривати дефект - той, хто його усунув?
Ні. Усунення і приймання - дві різні дії, і саме там рветься ланцюг. Виконавець позначає дефект як «Готовий до перевірки», а закриття залишається за тим, хто відповідає за якість. У хронології записується, хто прийняв.
Навіщо вести це в системі, а не в групі в чаті?
Чат не має статусу, не має терміну і ніяк не відповість на питання «які дефекти ще відкриті на цьому під'їзді». Через три місяці пошук в історії чату коштує дорожче, ніж ведення списку.
Що буде, якщо кінцевий термін мине?
Дефект підсвічується червоним і потрапляє в лічильник прострочених. Крім того, щоранку йде нагадування про терміни, які наближаються або вже минули, але лише для незакритих дефектів.