Пример пяти фраз, которые никогда нельзя говорить заказчику — они разрушают доверие и портят отношения:



1. «Это невозможно»
⛔️ Почему плохо: Звучит как отказ без попытки решить проблему.
✅ Что сказать вместо:
«Давайте разберём требования — найдём оптимальное решение»

2. «Это не по ТЗ» (сухо и без вариантов)
⛔️ Почему плохо: Кажется, что вам важно только формальное соблюдение условий, а не результат.
✅ Что сказать вместо:
«Это выходит за рамки текущего договора, но мы можем обсудить доп. опции»

3. «Мы всегда так делали»
⛔️ Почему плохо: Показывает негибкость и нежелание учитывать специфику проекта.
✅ Что сказать вместо:
«Обычно мы используем такой подход, но для вашего случая предложу адаптированный вариант»

4. «Это ваша ошибка» (даже если это так)
⛔️Почему плохо: Перекладывание вины злит заказчика.
✅ Что сказать вместо:
«Давайте проанализируем, как это произошло, и исправим»

5. «Я не знаю» (без продолжения)
⛔️Почему плохо: Подрывает ваш экспертный статус.
✅ Что сказать вместо:
«Уточню детали у команды и дам ответ до [время]»

Как я спасла горящий бюджет, превратив open source в «отечественное ПО»
Привет! Хочу поделиться кейсом, который начался с разговора у кофемашины. Ситуация:
🚨«Тендер на систему провален — заявился один вендор. ₽XX млн сгорят через 6 месяцев ... Open source? ФСТЭК не пустит!»

Предлагаю: «Может, сами напишем?»
— «Нет ресурсов!»
«Тогда все таки open source?»
— «ФСТЭК же не пропустит!»

🌝Но я не сдалась. Покопавшись в голове, вспомнила: не всё так безнадёжно! Есть кейсы, как это можно обойти.

💡 План спасения:
1. Берём XX систему (open source для крутых диаграмм).

Почему он?
- Бесплатен— лицензия GPL 3.0;
- Гибкий— диаграммы = текстовые файлы (удобно для Git);
- On-premise — ставится на сервер за 15 минут.

2. «Оботечествляем» или заменяем «рисковые» компоненты, пример:
- Меняем Graphviz → на Viz.js(российский аналог с MIT-лицензией),
- Java → на Axiom JDK (наш форк OpenJDK, реестр Минцифры).

3. Проверяем на ИБ:
- Solar appScreener сканирует код и далее чиним уязвимости,
- Готовим отчёт для ФСТЭК.

4. Регистрируем в реестре отечественного ПО (2-3 месяца, но бюджет уже не сгорит!).

5. Собираем MVP
Состав команды:
- 1 DevOps (развернуть инфраструктуру),
- 1 разработчик (интеграция с Viz.js),
- 1 ИБ-эксперт (подготовка к ФСТЭК).
Итог: MVP за 6 недель с командой из 3 человек!

Этапы:
mermaid
graph TD

A[Скачать ХХ систему]
B[Заменить Graphviz → Viz.js]
C[Интеграция с Astra Linux]
D[Аудит Solar appScreener]
E[Подача в реестр ПО]

Итого через 6 недель:
✅Рабочий прототип с диаграммами;
✅Отчёт для ФСТЭК (соответствие Приказу №239);
✅Дорожная карта для внедрения.