Web Дизайн. Уроки фотошопа, photoshop. Статьи о дизайне. Как создать сайт. Обучение дизайну. Фото. Гламурные галереи
Веб дизайн


Дизайн Форум


Про дизайн и web дизайн




Главная     Галереи Дизайна (29)




  Статьи о дизайне





  Галереи дизайна

Промышленный дизайн, графический дизайн, гламурные картинки, иконки, аватары.

  Помощь Дизайнеру!

Советы по дизайну. Философия, психология и трудовые будни дизайнера.



  Тим-лидер - лидер или придурок




Зачем нужен координатор web проекта и за что ему платят

В чем заключается работа координатора проектов (и в чем она не заключается).

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

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

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

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

Тим лидер web проекта

Пример работы тим-лидера

Есть заказ на сайт.
Координатор владеет всей информацией или придумывает ее на ходу - не важно. Главное, что он видит свой будущий проект и считает, что видит и общается по этому поводу с заказчиком. Кроме самого координатора всей информацией не обладает никто и его задача максимально просто донести ее до разработчиков. Причем постараться объяснить своей команде все так, чтобы понимание специфики и функционала будущего проекта было у разработчиков таким же, как и у координатора. Это важно сделать еще до начала работ. Приступая к работе исполнители должны четко и правильно понимать, что должно быть на выходе.

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

Но мы отвлеклись.
Итак, есть заказ на сайт и если координатор ступил - полной информации не знает никто, даже дизайнер которому поручается сделать то, не знаю что, по его усмотрению на основе какой-то неполной (и возможно будущей меняться) информации.

Что делает в этом случае дизайнер, правильно - он делает что и всегда, делает то, чему его учили, а именно визуализирует свое видение проблемы т.к. адекватного технического задание просто нет. Делает из ничего рабочую модель.

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

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

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

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

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

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

Верстальщик не всегда верстает по макету, вообще очень редко верстка в точности повторяет дизайн-макет. И все эти неверно отмеренные отступы и пробелы (казалось бы, какая мелочь) сильно портят впечатление. Верстку потом нужно проверять. Те. работа над сайтом должна вестись в комплексе, и то как сайт выгляди не менее важно чем то, как он работает.

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

В чем ошибки и в чем раздолбайство тим лидера

Вариантов много, вот основные:
  1. Он элементарно не захотел наладить общение внутри команды, он вообще ни с кем не общался кроме, например, программиста до момента сдачи проекта

  2. Он начал работу (дал к примеру задание делать дизайн макет) до конца не продумав структуру проекта, а постоянные переделки и неопределенность снизили мотивацию команды на успех проекта

  3. Он стал оценивать незаконченную работу, не предупредив о сроках сдачи и обвинять вебмастеров в том, что проект не будет сдан в срок и в таком виде как хочет он

  4. Он стал некорректно вмешиваться в работу членов команды, не являясь специалистом в области верстки или дизайна

  5. Он вообще не принимает участие в работе команды считая, что все должно делаться без его участия

  6. Он своим неадекватным поведением и неумением работать с командой настраивает разработчиков против себя. Это вообще финиш
Здесь не нужно ходить к гадалке, чтобы понять каким должно быть поведение и настрой координатора проекта. Резюмируя вышесказанное отметим, что это должно быть максимально доброжелательное ко всем разработчикам отношение. Критика только по делу и продуманные высказывания и замечания, которые воспримутся с уважением. И важно обеспечить максимальный своевременный поток информации по проекту для всех членов команды. А это значит, что тим лидеру нужно хорошо поработать, чтобы заработать на команде разрабов.

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

И если в ходе финального тестирования обнаружатся недоработки - их нужно будет переделать. А на этот случай стоит зарезервировать дополнительное время в общее время работы над проектом.

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


Миша К. декабрь, 2016 г.

Смотрите также:
Техническое задание
Техническое задание для заказчика








  Rambler's Top100  


Web дизайн и создание сайтов       Пользовательское соглашение

Карта сайта      Наверх