Дмитрий Ершов - Без ТЗ: Как запустить сервис и ничего не упустить. Аутсорсинг разработки цифровых продуктов
- Название:Без ТЗ: Как запустить сервис и ничего не упустить. Аутсорсинг разработки цифровых продуктов
- Автор:
- Жанр:
- Издательство:Литагент Ридеро
- Год:2018
- ISBN:9785449334930
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Дмитрий Ершов - Без ТЗ: Как запустить сервис и ничего не упустить. Аутсорсинг разработки цифровых продуктов краткое содержание
Без ТЗ: Как запустить сервис и ничего не упустить. Аутсорсинг разработки цифровых продуктов - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Чтобы не забыть
Если результат работы полностью устраивает, не забывайте благодарить исполнителей. Однако это вовсе не значит, что их нужно постоянно хвалить и постоянно с ними соглашаться. Помните о целях проекта. Если у вас возникнет альтернативная идея или незначительный комментарий – обязательно выскажите их.
Помните: недосказанность всегда работает против вас!
Когда вы постоянно соглашаетесь с исполнителем и не задаёте ему вопросов, велик риск, что он начнёт делать ошибки и удивляться, почему вы недовольны его работой. Раньше же было хорошо, а теперь всё не так. Работа над проектом должна проходить в формате диалога. Даже если вам всё нравится, узнавайте, почему исполнитель предложил именно такое решение.
Иной раз, задавая вопросы, вы сталкиваетесь с тем, что готового ответа на месте не найдётся. Обязательно фиксируйте непосредственно во время обсуждения все вопросы, договорённости, сроки решения и ФИО/контакты того, кто за это отвечает. Если вы общаетесь по скайпу – пишите всё это в сообщениях. Если лично – держите открытой почтовую программу и составляйте на ходу «протокол» совещания. Это позволит впоследствии не ломать голову над тем, кто кому что обещал и почему ничего до сих пор не готово.
После того как спринт полностью принят, не забывайте запрашивать инструкции к использованию результата. Эти инструкции в будущем могут сэкономить вам немало времени. Во-первых, их можно отправить человеку, которого нужно быстро ввести в курс проекта, а во-вторых, таким образом вы можете хранить историю проекта и при необходимости возвращаться к ней. Попросите разработчика записать скринкаст. Этот процесс не отнимет много времени, если его делать параллельно с демонстрацией или тестированием. Данные ролики можно выкладывать на видеохостинги и скрывать под паролем. Например, отлично подойдёт vimeo.com.
Заметки и истории
Доверие и контроль
«Правильный менеджмент» – это: 1) постановка задачи с измеримым результатом и ограниченным временем выполнения; 2) наблюдение и корректировка процесса, обратная связь; 3) вознаграждение за достижение результата.
Вроде все правильно. Но вот пунктом номер два ни один руководитель не любит заниматься. Почему? Потому что руководитель ленивый? Необязательно. Потому, что он подсознательно понимает, что это неправильно.
Пункт номер два – это чрезмерный контроль, который вреден бизнесу. Автор сам злоупотребляет этим, но старается все больше доверять и все меньше проверять, как идет процесс.
Вам не нужен менеджер, дизайнер или программист, которого нужно постоянно контролировать. Ставьте людям грамотные смарт-цели и ждите результатов в срок.
Если результатов нет по причине внешних факторов – расставайтесь. Если результаты плохие – корректируйте систему обучения.
– Но это слишком важная задача, чтобы рисковать, – скажете вы.
На это у меня для вас два ответа: 1. Начинайте проверять человека с менее важных задач. Усложняйте задачи по мере повышения доверия. Ваша цель – прийти к постановке задач, которые вы считаете невыполнимыми. 2. Нужно ли вам иметь дело с человеком, которому вы не можете доверить важную задачу? Кому вы собираетесь тогда поручать важные дела?
Доверяйте людям и перестаньте контролировать каждый их шаг.
Олег ЧулаковНе принимайте то, что не нравится
Далеко не все истории о моей работе в веб-студии повествуют об успехе и удаче. Был и негативный опыт негативный опыт сотрудничества с крупной юридической фирмой, который дал мне понять, что всегда есть кто-то, кто может сделать работу лучше.
Во время проекта мы часто общались с заказчиком на повышенных тонах, потому что не могли друг до друга достучаться. Я в качестве аккаунт-менеджера со стороны студии, изо всех сил защищающий работу неопытного дизайнера, и молодая девушка-секретарь заказчика, которая хочет сказать, что дизайн оставляет желать лучшего, но не может это выразить.
Сайт был запущен и проработал какое-то время, а потом его заменил сайт с тем-же контентом, только с более крутым уровнем архитектуры, дизайна и вёрстки. Оказалось, что после подписания с нами закрывающих документов юрфирма сразу обратилась к более опытным разработчикам, которые быстро обеспечили необходимый результат.
Отсюда следующий вывод: если вас не устраивает результат – не принимайте его и попробуйте сменить исполнителя (например, дизайнера интерфейсов внутри студии). Оперативное реагирование на такие сигналы поможет добиться целей гораздо быстрее.
Заключение

Некоторые разработчики любят демпинговать на этапах проведения конкурса, чтобы получить проект, после чего производить дорогостоящие доработки, на которые вы не рассчитывали. В этом случае запросите экспресс-оценку на необходимые доработки у выбранных ранее подрядчиков, и если оценка текущего подрядчика будет на порядок выше – ваши опасения оправдались. Смело выбирайте нового исполнителя. Чтобы смена подрядчика прошла наиболее гладко, тщательно принимайте проект со всеми материалами и документацией.
Если вы создавали все необходимые документы, покупали время, а не промежуточные результаты работ и контролировали исполнение, то неприятного осадка от работы у вас остаться не должно. При этом у вас наверняка сформировалось множество мыслей и планов. Распределите эти идеи по следующим релизам продукта – и получите прекрасный план по развитию.
С одной стороны, не стоит выбрасывать все идеи, чтобы когда-нибудь всё сломать и сделать «систему 2.0», а с другой – не стоит развивать продукт внезапно.
Сначала подтвердите ваши основные идеи по продукту. До его запуска ваши гипотезы могли служить поводом для разработки того или иного функционала, но сейчас все задачи по доработке должны генерироваться исходя из статистики поведения и реальных целей пользователей.
Спасибо за то, что прочитали эту книгу. Надеюсь, теперь вы чувствуете себя более подготовленными к проблемам аутсорсинга разработки.
Успехов!
Материалы
Полный список инструментов из книги и дополнительные материалы вы можете найти на сайте beztz.net.
Благодарности
Благодарю за терпение и заботу всех, кто помог создать эту книгу. Олега Чулакова за заметки. Агентство The Headза креатив на обложке. Андрея Бухвина за дизайн, а Наталию Качалину за редактирование рукописи.
Я благодарен Арслану Разыкову, Максиму Храмову и Ольге Дрозд за ценные замечания. И конечно, я благодарю свою жену, которая часто засыпала под стук моих пальцев по клавиатуре.
Интервал:
Закладка: