Baseline (водокре́с) ⛴️

💵 На одних курсах по фінансовій обізнаності почув цікаву думку. Типу, в кожного з нас є “мінімальна допустима норма” нашого фінансового стану. Це такий рівень, який ми готові “толерувати” (з яким готові миритись) і нижче якого не готові спускатись. І ми приблизно завжди знаходимось десь в цій точці нашого мінімуму, яка доречі теж змінюється.

⛴️ В роботі кожної команди в кожній активності можна відслідкувати деякий baseline (чи ватерлінію), стандарт якого притримуються. Наприклад, обов’язково 100% покриття тестами. Або, не запізнюватись на мітинги. Або, обов’язкова документація. Або, технічний дизайн перед імплементацією.

🥛 Це культура, яку ви підтримуєте і розвиваєте. Іноді, мені навіть простіше стало її розмежовувати на “над baseline”ом чи “під baseline’oм”. Тобто, якщо хтось не пише тести, то це нижче нашого встановленого стандарту. Таке собі приведення до булеану.

💪 Хтось в команді постійно намагається підняти цей рівень стандарту: посилює типізацію, пропонує додаткові процеси для поліпшення якості, пропагандує 100% покриття тестами і zero-error policy. Хтось просто слідує “правилам”, тому середньому рівню, приймає зміни але не часто пропонує свої.

🏖️ Але є і ті, хто постійно буде намагатись опустити цей рівень якості якнайнижче. Адже погіршення завжди можна обґрунтувати: на тести не вистачило часу, на zero-error policy не було чіткої задачі.

То ж однією із своїх задач, як тімліда, я визначив бути quality keeperом, слідкувати що б наш Baseline розробки не спускався, а навпаки, піднімався. Адже зі зростом кодової бази зростає складність, то ж що б “залишатись на місці треба бігти з усіх ніг”.

🏦 З фінансами так само: dream big (стати мільйонером, купити порше) дуже важливо. Але також спробуйте підняти рівень свого допустимого мінімуму трохи вище. І ось тут можна знайти наступні кроки, які варто робити що б іти вище.