Обо мне

Привет, меня зовут Никита Зайцев, 21-летний Web developer. Я умею создавать сайты (wordpress, bitrix и др), интерфейсы, курировать проекты и не срывать сроки. А ещё люблю кофе.

Чем я полезен?

Доработки

Начиная от интеграции api, заканчивая ускорением сайта

Лендинги

Действительно крутые ленды с конверсией от 30%

Разработка

С 2016 года активно создаю сайты. Например, сайт для top15ufa.ru

Тестирование

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

Представляем себе точку А, в которой находимся, точку Б, в которой хотим оказаться, и идеальную линию, которая соединяет эти две точки,— это план проекта:

Самая большая ошибка — предполагать, что проект пойдёт, как задумано.
Проект — это путешествие из точки А в точку Б, полное неожиданностей и приключений.

Начиная движение, проект сталкивается с сопротивлением окружающей среды. Дизайнер забывает учесть сложный случай. Клиенту не нравится дизайн. Разработчика тормозит проблема в реализации. Кто‑то заболевает. У кого‑то ломается компьютер. Можно перечислять возможные сюрпризы, но в каждом проекте будут свои. 

Проект движется и колеблется вокруг идеальной линии, и, возможно, придёт
в совсем другую точку Б’

«Нельзя реализовать задуманный проект за 100% времени, 100% денег, со 100%‑й функциональностью и без потери качества. При отклонении от курса придётся чем‑то пожертвовать. Чем именно — жизненный выбор.»

— Закон о потерях

Репутация зарабатывается годами, а теряется за один день. Жертвовать качеством — не вариант.

Фиксируем срок. Если не успеваем сделать вовремя, обычное решение — сдвинуть срок запуска. Но время — невосполнимый ресурс, недаром deadline происходит от слова «смерть». За отпущенное нам время мы успеем только то, что успеем. Чтобы не уходить в мрачные аналогии, сравниваем запуск проекта с наступлением Нового года. Отодвинуть его нельзя, даже если ты не успел купить подарки. Не сдвигаем срок.

Фиксируем бюджет. Когда проблемы в проекте решают деньгами, это означает одно из двух: либо оплачивают дополнительное время, либо расширяют команду. Первое не подходит, проект может не оправдать ожиданий. А увеличение команды нередко снижает управляемость проекта и только усугубляет его проблемы.

Флексим. Когда жертвовать сроком, бюджетом и качеством нельзя, методом исключения приходим к одному: жертвуем функциями, «флексим». Отрезаем то, что не успеваем сделать.

Этот вариант — большая удача:

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

Чем больше функций, тем больше их пересечений, а значит мест для ошибки. Поэтому отказ от функции помогает уменьшить количество узких мест и повысить качество первой версии.

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

Новый продукт с небольшим числом функций легче объяснить пользователям. Только мы знаем о том, что часть идей не реализовали. Пользователям они бы только добавили сложностей.

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

Флексить страшно - даже мне

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

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

С проектами иначе. У Колумба в экспедиции были бунты, болезни, поломки и штормы. И в результате он открыл вовсе не ту страну, на путешествие в которую собирал деньги.

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

В продукте будет меньше функций, чем изначально планировалось

Флексить больно

Одно дело решить делать зарядку по утрам, другое дело — делать её. Когда приходит время отказаться от какой‑то задумки, больно всем. Дизайну больно, потому что они придумали классную фишку, но её не будет в продукте. Разработке обидно, потому что пришлось потратить силы на разработку, тесты, а её пришлось убрать. Но больнее всех клиенту, который придумал проект и имел от него свои ожидания.

Не все готовы к этой боли.

Больнее всех — клиенту

Клиент — предприниматель

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

Чтобы сделать проект без директора или с минимальным его участием, нужно либо лишить его права голоса (что звучит неправдоподобно), либо попросить его делегировать задачу человеку, которому он полностью доверяет.

Опыт показывает, что если пытаться угодить нескольким «клиентам» одновременно, проект получится болезненным, а продукт — беззубым и компромиссным. Я с большей долей вероятности, не смогу взяться за проект, в котором больше одного командира

Работаю с тем, кто принимает решения

Результат — это пуск

Обычно дизайнеры отдают клиенту картинки. И в закат

Но большинство дизайнерских решений принимается на этапе разработки. Что произойдёт, если пользователь нажмёт на эту кнопочку при незаполненной форме? Что делать, если в реальной базе данных на странице оказывается в три раза больше текста, чем предусмотрено дизайном? Как выглядит 404‑я ошибка при ширине экрана 2000 пикселей? А на твоём пейджере как выглядит?

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

Дизайн не заканчивается на картинках

Никаких сюрпризов

Как идёт проект по fix time, fix budget, flex scope? В самом начале мы подписываем договор, прописываем этапы от начала работы до пуска. Для каждой недели известна работа и результат.

Самый страшный грех — принести клиенту в последний день половину проекта и спокойно сказать «успел только это». Сколько бы ни обсуждался флекс перед началом проекта, любой клиент будет возмущён, если его просто поставят перед фактом, что чего‑то не будет.

Когда возникает угроза сроку, приходится принимать решение об упрощении дизайна или ограничении функциональности. Предлагаю решение, клиент принимает его или предлагает своё. Достижение договорённости о «флексе» — наша взаимная ответственность с клиентом.

Разбиваю большой проект на короткие итерации с регулярными пусками

Делаю крутые вещи с

Интересный факт

16+ ЗАВЕРШЕННЫХ ПРОЕКТОВ КОТОРЫЕ «ВЗЛЕТЕЛИ»‎ НО БОЛЬШИНСТВО ПОД NDA 😂

16+ ЗАВЕРШЕННЫХ ПРОЕКТОВ КОТОРЫЕ «ВЗЛЕТЕЛИ»‎ НО БОЛЬШИНСТВО ПОД NDA 😂

МИНИМУМ 7  КНИГ ПО ПРОГРАММИРОВАНИЮ ПРОЧИТАНО

МИНИМУМ 7 КНИГ ПО ПРОГРАММИРОВАНИЮ ПРОЧИТАНО

4800+ Правок выполнено

4800+ Правок выполнено

БОЛЕЕ 3000 кофе за разработкой

БОЛЕЕ 3000 кофе за разработкой

Текст о ФФФ (fix time, fix budget, flex scope) взял у БЮРО за что им огромное спасибо!