x
 
↑
Декабрь
•
7 •
•
2 •

2 •
↓
Андрей К.
3 декабря 2015
Советы почтой каждую неделю
Пожалуйста, получите наше письмо, чтобы подтвердить свой адрес:
Вы подписаны на «Советы за неделю»:

Предположим, компания работает по ФФФ. По плану ведения проекта за неделю нужно запрограммировать функцию. Если получится, что сделать её никак не удаётся (не хватает профессионализма разработчикам или данные потерялись), и в конце выяснится, что за неделю никакого видимого результата нет, должен ли клиент оплачивать это время?

Андрей!

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

Хочу обратить внимание читателей на важнейший принцип работы со сложными задачами — принцип «сделать невидимое видимым». Если вы делаете задачу, где сначала надо долго делать что-то непонятное для клиента, а потом, когда внутренняя структура будет готова, всё волшебным образом доделается, ваша задача придумать, как сделать видимой внутреннюю работу, иначе клиент будет переживать.

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

  • Во-первых, процесс проектирования должен следовать принципу «сделать невидимое видимым». Если то, что делает фронтендер, всегда на виду, то бэкендер по определению занимается скрытой логикой. В проекте сюрпризы не нужны, поэтому логика должна быть описана разработчиком в спецификации, покрыта тестами, а затем сделана видимой всем участникам как можно раньше в прототипе, пусть с заглушками.

    Во-вторых, публикация и откат версий должны быть продуманы изначально. Повседневная ситуация: одновременно разрабатываем новую функцию и исправляем баги, публикуем легко и непринуждённо. Откатываем тоже. Деплой туда-сюда, тыры-пыры. В-третьих, систему надо строить так, чтобы не составляло труда прикрутить статистику к любой кнопке или событию, провести А/Б-тест, проверить гипотезу.

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

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

Пример применения принципа «сделать невидимое видимым» в дизайне.
P. S. Это был совет об управлении проектами, людьми и собой. Присылайте вопросы.

P. P. S. Я веду практический курс «Управление проектами, людьми и собой». Дата следующего курса пока неизвестна.

 
Мы напишем вам, когда будет открыта запись. Без спама.

Поделиться
Отправить

Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

Решение о публикации принимается один раз; мы не имеем возможности комментировать или пересматривать свое решение, хотя оно может быть ошибочно. Уже опубликованные комментарии могут быть удалены через некоторое время, если без них обсуждение не становится менее ценным или интересным.

Вот такой веб 2.0.
Ушли из компании, но хотите вернуться Страшно запускать свой курс Хочется схантить сотрудника у клиента Невозможно собрать портфолио 1 •




Недавно всплыло

Выбранные элементы списка, как не забывать принципы из советов бюро и когда нужен логотип 1 • 1 • 1 • 1 •