Рубрика: Разработка

  • Пройти Тест Джоэля

    Пройти Тест Джоэля

    В 2000 году Джоэль Сполски — сооснователь StackOverflow и Trello, написал список из 12 вопросов, известные как Тест Джоэля. Часто ссылаюсь на этот тест, поэтому прокомментирую эти вопросы.

    1. Используете систему контроля версий?
    Кажется, что git — уже обязательная вещь. Но до сих пор встречаются проекты без системы контроля версий.
    Для тех, кто уже использует, вопрос всё ещё актуален, но теперь звучит так: Вы действительно используете систему контроля версий? У вас есть стратегия ветвления, процедура слияния веток, понятные правила для работы с репозиторием?

    2. Сборка проекта происходит в один шаг?
    Проект должен собираться в 1 команду и она должна быть написана в readme. Если для запуска проекта требуется поставить несколько сервисов, иметь нужную версию компилятора и запущенную базу данных — стоит прописать все эти зависимости в docker-compose и запускать одной командой. После прихода виртуализации оправданий для многошаговой сборки и зависимости от среды больше нет.

    3. У вас настроен CI/CD?
    В оригинале Джоэль говорит про daily build — оперативная сборка софта каждый день. Сейчас в большинстве команд нет нужды синхронизировать код раз в день, можно делать это автоматически каждый раз, когда код попадает в репозиторий.
    Настройте автоматическую сборку и выкатку приложения на тестовый сервер.

    4. У вас же есть база багов? Правда?
    Громоздкая Джира не единственный вариант. Эксель тоже подойдёт! Если у вас есть общий зафиксированный список проблем, вы можете с ними работать и планировать их устранение.

    5. Вы чините баги до написания нового кода?
    Технический долг на проектах с горящими сроками не вызывает вопросы. Но когда сроки сгорели, вы же выделяете время на рефакторинг и устранение багов? Команду не просто демотивирует развивать новые фичи в продукте, когда в фундаменте есть проблемы. Это приводит к плохим архитектурным решениям и обрушению новых этажей.

    6. У вас есть план работ со сроками?
    План, который знают все и который связан с реальностью. Roadmap, этапы или просто дата, в которую надо запуститься.
    Работа ведёт себя как газ — занимает всё выделенное время. Ставьте сроки.

    7. У вас есть спецификация?
    Банально, но без ТЗ результат ХЗ. Сейчас не нужно писать исчерпывающее финальное тех задание — требования поменяются по ходу разработки. Достаточно написать концепцию, сделать прототипы, записать user story и опубликовать. Задачи тоже нужно записать и поставить в трекер.

    8. У разработчиков есть тихие рабочие места?
    Ваш разработчик всё ещё сидит в опенспейсе? Зря-зря. Скорее всего, он уже обзавёлся наушниками и пытается от вас отвернуться. Помогите ему создать изолированную среду.

    9. У разработчиков лучшая техника и инструменты?
    Быстрый комп, 2ой монитор, современный софт, быстрые серверы — стоят копейки относительно времени программиста. Планка памяти стоит как час работы разработчика. Ускоряйте их всеми доступными способами, это очень дёшево.

    10. У вас есть тестировщики?
    Если баги ищут только разработчики — значит, баги находят пользователи.
    Менеджеры и программисты проверяют, что код работает. Тестировщики проверяют, ищут где он не работает. У вас должен быть хотя бы 1 тестировщик в команде на нескольких разработчиков.

    11. Пишут ли кандидаты код на собеседовании?
    Это единственный пункт, с которым я сейчас не полностью согласен в его изначальной формулировке. Изучить код и мышление кандидата на собеседовании получится, а вот показать реальные навыки в стрессовой ситуации собеседования — вряд ли. Мой рецепт — выводить подходящих кандидатов на тестовую неделю и смотреть совместимость без давления в реальной обстановке.

    12. Вы делаете usability тесты на добровольцах?
    Соберите группу для тестирования. Первые 5 случайных пользователей укажут вам на 95% проблем. Находите этих пользователей и проводите тестирование до большого релиза. Это дёшево и просто. В оригинале предлагается поймать добровольца в коридоре компании, но сейчас эра удалёнки — найдите их онлайн.

    Если вы фаундер или руководитель и у вас есть ответы “Нет” — их точно стоит обсудить с командой.

  • Горшочек с мёдом

    Горшочек с мёдом

    Honeypot — в переводе с английского “горшочек с мёдом”. Красивое и безобидное название, которое в веб-разработке обозначает хитрую ловушку. Ловим роботов! Ловим в естественной среде обитания — на нашем сайте, на самую обычную форму регистрации, комментария или обратной связи.
    Обычный пользователь видит свою обычную форму:
    Имя: ____________
    Email: ___________
    Ваш комментарий: ____________________

    Робот не смотрит глазами на монитор — он читает исходный код. И видит робот ещё одно поле.
    Фамилия: __________
    Ничего подозрительного, просто ещё одно поле. Нужно заполнить! А это и есть наш горшочек с мёдом.
    Настоящий пользователь это поле не увидел — мы его скрыли с помощью CSS. Он отправил форму с пустой фамилией. А старательный робот фамилию заполнил.

    Попался!
    Мы его игнорируем: заполненная форма уничтожается, письма не отсылаются, аккаунт не регистрируется. Спам не прошёл!

  • Почему Fix Price — это ловушка

    Почему Fix Price — это ловушка

    По данным PMI, средний большой IT-проект превышает бюджет на 45%, сроки на 7%, а выхлоп даёт на 56% меньше ожидаемого.
    В исследовании Harvard Business Review, каждый шестой IT-проект обошёлся более чем на 200% дороже и вышел за сроки более чем на 70%.
    Люди плохо оценивают трудозатраты. Не учтены все внешние факторы, слишком оптимистично оценивается время и ресурсы. В процессе работы с проектом приходит более глубокое понимание предметной области и деталей.
    Мы интуитивно ожидаем нормальное гауcсово распределение по срокам, но в реальности у нас распределение с тяжёлым хвостом. Это значит, что редкие, но очень долгие проекты — не исключение, а закономерность.

    Заказная разработка такая странная отрасль, где многие подрядчики берут на себя риски, которыми не управляют. Студии кажется, что в этот раз точно получится уложиться в бюджет и сроки. И на фиксированной цене очень настаивает клиент.

    Чем это заканчивается:
    – Клиент недоволен, что сроки не соблюдены. Прогноз всегда ошибочен, но клиенту пообещали эксперты.
    – Не попадаем в оценку трудозатрат. Не редки случаи, когда студия уходит в минус просто чтобы довести проект до конца.
    – На проекте тлеет, а затем разгорается пожар конфликта. Может дойти до суда.
    – Все недовольны и демотивированы.

    Проекты по модели Fix Price можно брать, но если есть ряд условий:
    – Вы уверены, что в проекте нет рисков.
    – В проекте очень мало неопределенности. Например, у вас уже почти всё готово, осталось прилепить логотип заказчика сверху стандартной заготовки.
    – У вас наценка от 500% на качественно просчитанную себестомость.

    Точная оценка нового проекта — иллюзия. Большой проект с неопределённостью нельзя брать по фиксированной цене. Каждый раз, когда вы берёте большой проект по Fix Price в надежде, что получится заработать, вы играете в рулетку.

  • Как быстро провести аудит чужого кода с помощью AI

    Как быстро провести аудит чужого кода с помощью AI

    Как быстро провести аудит чужого кода с помощью AI.

    Я смотрю достаточно много репозиториев с чужим кодом. Нужно разобраться как работает, найти проблемные места и поговорить с разработчиком предметно.

    Моя версия, как сделать аудит кода с помощью AI:
    Клонируешь репозиторий.
    Запускаешь Cursor AI — форк VS Code с встроенным AI.
    Ждёшь пока Cursor проиндексирует код и построит локальную базу.
    В это же время в чат с ChatGPT загружаешь файлы package.json, composer.json, requirements.txt, gitlab-ci.yml, docker-compose.yml или что у вас там в корне лежит.
    Формулируешь задание написать промпт на английском языке для другого AI, который будет проводить аудит кода. Указываешь все аспекты и особенности, на которые хочешь обратить внимание. Можно попросить сфокусироваться на безопасности или тех долге.
    GPT пишет промпт на пару страниц и этот промпт вставляешь в Cursor AI.

    Cursor выдаёт гигантские подробные заключения с разбором стиля, архитектурных ошибок, технического долга, перегруженных классов, дырок в безопасности, нарушений паттернов проектирования и другими аспектами.
    Результат получается с галлюцинациями, но экономит много времени. Точно понятно, что в коде смотреть и какие вопросы авторам задавать.

    PS: Очень полезно запускать такой аудит на своём проекте.

  • Оргструктура для стартапа — как назначить всем должность

    Оргструктура для стартапа — как назначить всем должность

    Оргструктура для стартапа — как назначить всем должность.

    Пока компания небольшая и все делают всё, очень большой соблазн не проектировать структуру организации. Особо самоуверенные предприниматели игнорируют её годами. Грабли детские, поэтому бьют особенно больно ниже пояса.

    Я выписал всё, чем нам нужно заниматься. Разработкой всё не ограничивается. Огромное количество действий поглощает рабочие дни команды: продажи, редакция, партнёрская программа, маркетинг, PR, финансы, бухгалтерия, HR, секретарь, служба поддержки, продукт, разработка, дизайн, интеграции, тестирование, юридические аспекты, инвестиции.

    И попробовал рассортировать по кучкам. Потом на эти кучки можно будет приклеить ярлычки CEO, CFO, CMO, C3PO, R2D2…

    Через 40 минут сортировки на доске я понял, что у меня не стыкуется. Текущая команда и виртуальная структура с дырками… В общем, заставил GPT воображать себя венчурным инвестором и успешным предпринимателем, после чего скормил ему эту задачу. Описал всех участников, рассказал, кто чем занимается и дал список направлений деятельности.

    Такое распределение менеджмента получилось в итоге:
    1. CEO (Chief Executive Officer) + CTO (Chief Technology Officer). Генеральный + технический директор. Стратегия и руководство, технические вопросы, финансы, инвестиции.
    2. COO (Chief Operating Officer) + CRO (Chief Revenue Officer). Операционный директор + РОП. Продажи, управление редакцией, онбординг новых клиентов и сотрудников.
    3. Head of Design & UX/UI — Дизайнер.
    4. Head of Customer Support — Поддержка клиентов.
    5. Head of Marketing (потенциально CMO) — Маркетолог.

    Забавно, что AI назначает Head of, даже если в отделе один специалист. Но мы помним, что в стартапе карьерные ступеньки подставляют вниз. Ещё интересно, что не все участники команды получили позицию менеджера. Даже если этот участник в отделе один.

    Теперь дополнительная польза. Кого можно сейчас не нанимать?
    Chief Product Officer (CPO) — Директор по продукту. В нашем случае закрывается созданием продуктовой команды из CEO/CTO + COO + Design. Лучшее решение, спасибо искусственным мозгам! Что интересно — ровно так разработка у нас и происходит. Находка, что можно не выделять главного в этом процессе и продолжать работать коллективом.

    Chief Financial Officer (CFO) — Финансовый директор. Когда деньги появятся, тогда и возьмёте. Для меня отличным решением оказалось раннее выделение роли Chief Revenue Officer без довеса на эту роль функционала CFO. И правда, чем управлять? Продавайте пока и всё.

    HR-менеджер — Управление персоналом пока больше сводится к найму. Это закрывают сами CEO и COO, а что не смогут — отдать рекрутерам. Мы можем долго не нанимать выделенного HR, потому что оба фаундера много нанимали сами в других проектах.

    Юрист — аутсорсить на точечных консультациях (это мы уже начали) или взять агентство (а вот это пока навряд ли).