Вадим Юмадилов
31 декабря 2015
Советы почтой каждую неделю
Пожалуйста, получите наше письмо, чтобы подтвердить свой адрес:
Вы подписаны на «Советы за неделю»:

Николай!

Расскажите, как работать с разработчиками на стороне клиента?

Допустим, мы делаем сайт. Разработчик проваливает сроки, сливается и редко показывает работу. Как добиться результата? Какую роль в таком случае отводить клиенту?


Вадим!

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

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

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

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

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

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

Не попадайтесь в ловушку, не работайте с теми, в ком не уверены.

С наступающим!

Тест на техсовместимость
P. S. Это был совет об управлении проектами, людьми и собой. Присылайте вопросы.

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

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

Поделиться

Комментарии

Владимир Тицкий
31 декабря 2015

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

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

В рабочих отношениях классно торговать проблемами и выкладывать багаж до того как проблема случится. Это экономит время и нервы в большинстве случаев.

Александр Миндеров
1 января 2016

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


7 января 2016

Александр, в конце пятого абзаца мы проект ещё не взяли. Работоспособность команды проверяют до начала работы.


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

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

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

Вот такой веб 2.0.

Как флексить. Отступить от идеала 2 Как защищать ОЧЕНЬ простые дизайнерские решения?

Как же мне сделать систему, удобную и понятную для конечного пользователя?

2
Как флексить: сделать говно




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

Как должна работать прокрутка? 2 4 Я бы покрасил стены новой рабочей студии белой краской. А коллега хочет клеить обои 3 1



© 2007—2017

Запрещённые слова
Пишите: mail@artgorbunov.ru