Комментарии 19
А теперь замените программистов на строителей, которым редакция заказывает строительство офиса. Пройдет такой подход? Врядли.
Ладно :)
Раньше тоже сравнивал создание веб сайтов со строительством зданий. Теперь думаю что это сравнение не совсем корректно. Строительство зданий скорее можно сравнивать с созданием дата-центра или настройкой серверов, ну или созданием веб-движка (CMS). Создание веб-сайта это скорее декорация офиса, расстановка мебели, создание витрины: эти вещи постоянно меняются, а здание (основа) остается.
Это смотря какой сайт вы делаете. С узкоспециализированными сайтами для которых есть ходовые движки (блог, магазин) — да. Это взять тему и разукрсить под заказчика — декорация.
Если вам нужно спроектировать что то уникальное вроде скидочного сайта или узкоспециализированной социальной сети: здесь уже проектирование.
Как и в строительстве: постройка дома это изначально проектирование. Так и здесь все осталось по-прежнему. А если вы принимаете участие в группе, которая занимается декорацией — ведь это не значит, что вся индустрия работает точно так же. Верно?
Если вам нужно спроектировать что то уникальное вроде скидочного сайта или узкоспециализированной социальной сети: здесь уже проектирование.
Как и в строительстве: постройка дома это изначально проектирование. Так и здесь все осталось по-прежнему. А если вы принимаете участие в группе, которая занимается декорацией — ведь это не значит, что вся индустрия работает точно так же. Верно?
Что-то вы плохо понимаете про постройку дома. При постройке дома точно так же берётся типовой проект и, максимум, подгоняется под рельеф местности. А дальше только декорации. Разница только в том, что типовую CMS легче скопировать — залил на хостинг, настроил и уже летим. А дом по типовому проекту ещё строить надо.
Опять таки: типовый проект. Конечно, в наши дни типовое можно встретить гораздо чаще, чем не-типовое, на то и время копирования и масштабирования. Но все таки индивидуальные строения делаются и им отводится гораздо больше внимания, да и отдачи они дают гораздо больше. Нетипичные небоскребы в Батуми, например гораздо выше ценятся, чем типичные многоэтажки. Я к тому, что даже не в сайтах, а в комплексных довольно больших проектах, не редко проектирование и оно востребовано. Сложно наверное представить проект Фейсбука развернутый на какой ни будь CMS, ведь так же? Я не спорю, что есть уже CMS реализующие функционал социальной сети, но например проект по бронированию такси через вебсайт — это уже достаточно нетривиальная задача для обычной CMS.
НЛО прилетело и опубликовало эту надпись здесь
Мне всегда нравилась метафора с машинами. Во многих предложениях если заменить «сайт» на «автомобиль», особенности разработки сразу становятся понятны всем.
— Сколько стоит автомобиль?
— Какие задачи должен выполнять автомобиль?
— Автомобили бывают разные. Для некоторых задач нужен фургон, а для некоторых гоночный болид.
Чертовски просто.
— Сколько стоит автомобиль?
— Какие задачи должен выполнять автомобиль?
— Автомобили бывают разные. Для некоторых задач нужен фургон, а для некоторых гоночный болид.
Чертовски просто.
Капайте разработчику на мозги, «воспитательную работу с командой»… моя плакать. От плохого менеджера веет за версту. Если разработчики закопались в коде — это уже ваш недочет. При наличии манагера, разработчику и вовсе не рекомендуется общаться с заказчиком, чтобы не стать «козлом отпущения».
Поясните пожалуйста, почему разработчику «не рекомендуется» общаться с заказчиком и почему и как от общения с заказчиком разработчик станет «козлом отпущения»?
Предполагаю, что имеется ввиду то, что разработчики как правило не подкованы в деловом общении. В итоге если такой программист сойдётся в переговорах с ушлых заказчиком, умеющим навешать лапшу на уши, то битву программист проиграет. Совсем другое дело — натасканный в переговорах менеджер, который лапшу заказчика ему самому и скормит.
делать многое, что, по идее, менеджер делать вроде как не должен. Нужно писать мануалы, чертить схемы бизнес-процессов, успокаивать возмущенных людей по телефону, и прочее, и прочее
А кто это должен делать, как не менеджер? Правильный менеджер — контактирует с заказчиком, разбирается в предметной области, и предоставляет для конкретных разработчиков «хотелки» в нормализованном виде — схемы бизнес-процессов, диаграммы use-case и прочее. В лучшем случае, проработка этого идет вместе с lead-ом. Если менеджер просто бегает между заказчиком и разработчиками, уговаривая каждого пойти на компромисс — грош цена такому менеджеру.
Может пару примеров как были разрулены те или иные ситуации? А то какая-то слишком общая статья.
Описанная вами ситуация с редакцией — это точная копия очень многих малых бизнесов, когда на отдельного менеджера для ведения диалогов с разработчиками просто не выделен бюджет.
Ситуация знакома очень. Я её ощущала на себе не раз и сделала один очень важный вывод — работать с подобными заказчиками надо по протоколу, вне зависимости от их занятости и загруженности.
Вы описали ситуацию «сверху», но она ничем не отличается от ситуации «снизу». Вот именно эта такая ваша гибкость в работе с клиентами однажды стоила мне отказа в трудоустройстве на вашу должность в одну из лучших студий Москвы.
Подстраиваться непременно нужно, ведь мы все живые люди с чувствами и личными убеждениями, но лишь в рамках, строгих рамках ведения проектов.
Ситуация знакома очень. Я её ощущала на себе не раз и сделала один очень важный вывод — работать с подобными заказчиками надо по протоколу, вне зависимости от их занятости и загруженности.
Вы описали ситуацию «сверху», но она ничем не отличается от ситуации «снизу». Вот именно эта такая ваша гибкость в работе с клиентами однажды стоила мне отказа в трудоустройстве на вашу должность в одну из лучших студий Москвы.
Подстраиваться непременно нужно, ведь мы все живые люди с чувствами и личными убеждениями, но лишь в рамках, строгих рамках ведения проектов.
Прямо как бальзам на душу в плане Вики! Сам сейчас постепенно прихожу к необходимости такие вещи делать. На каких-то проектах организуем такую штуку через Trello, хотя структура, конечно, хромает.
Спасибо за идею GitHub. Нужно будет попробовать.
Спасибо за идею GitHub. Нужно будет попробовать.
Одно из преимуществ wiki на GitHub – возможность редактировать файлы локально на компьютере, работая как с репозиторием. Так как менеджеры с терминалом работать не умеют, на помощь приходят настольные приложения для git. В частности, можно скачать GitHub for Mac. Репозиторий с wiki для проекта лежит по адресу
git@github.com/username/reponame.wiki.git. То есть к адресу обычного репозитория добавляется суффикс .wiki. Один раз настраиваем, показываем как делать коммиты, кликая вон ту зелёненькую кнопку. И все довольны.
Переименуйте статью в «Если менеджер проекта морская свинка».
«Перезапускали» недавно небольшое региональное медиа издание. В общих чертах ситуация похожая.
НО, не нужно это преподносить как некую неизбежность, типа если заказчик редакция — даже не пытайтесь.
Аргументы «нет времени» звучат смехотворно — ни у кого никогда нет времени, все заняты, в конце концов ИТ специалистам тоже есть что почитать и пописать. У нас время нашлось.
ТЗ отсутствовало за ненадобностью. Были чёткие цели редизайна, далее были макеты, далее пожелания редакции и внесение небольших изменений в основном в очень специфичные проекты. Когда все понимают «зачем это всё вообще», и главное дизайнер, правок не так уж много. Далее программистам нужно было «натянуть» вёрстку, они решили что тз для этого им ненужно, хотя для выполнения задачи требовались небольшие изменения в структуре данных. Все «а добавьте сюда кнопочку» оставлялись на усмотрение разработчика, либо делалось сразу, либо откладывалось на потом(после редизайна), и необходимость в большей части этих «хотелок» отпала сама собой, через пару недель, когда редакция полностью «въехала» в новые правила публикации материалов.
Все участники очень переживали, что результат не оправдает надежд, долго тянули с выводом в продакшн, смотрели/думали опять смотрели, но в итоге всё прошло достаточно гладко.
И главное сейчас я понимаю, что можно лучше, быстрее проще организовать процесс, что это не так уж и сложно как может показаться на первый взгляд.
Вы же свой не самый лучший опыт выставляете неким эталоном, чтобы другие какбы равнялись. По крайней мере я так понял посыл статьи.
НО, не нужно это преподносить как некую неизбежность, типа если заказчик редакция — даже не пытайтесь.
Аргументы «нет времени» звучат смехотворно — ни у кого никогда нет времени, все заняты, в конце концов ИТ специалистам тоже есть что почитать и пописать. У нас время нашлось.
ТЗ отсутствовало за ненадобностью. Были чёткие цели редизайна, далее были макеты, далее пожелания редакции и внесение небольших изменений в основном в очень специфичные проекты. Когда все понимают «зачем это всё вообще», и главное дизайнер, правок не так уж много. Далее программистам нужно было «натянуть» вёрстку, они решили что тз для этого им ненужно, хотя для выполнения задачи требовались небольшие изменения в структуре данных. Все «а добавьте сюда кнопочку» оставлялись на усмотрение разработчика, либо делалось сразу, либо откладывалось на потом(после редизайна), и необходимость в большей части этих «хотелок» отпала сама собой, через пару недель, когда редакция полностью «въехала» в новые правила публикации материалов.
Все участники очень переживали, что результат не оправдает надежд, долго тянули с выводом в продакшн, смотрели/думали опять смотрели, но в итоге всё прошло достаточно гладко.
И главное сейчас я понимаю, что можно лучше, быстрее проще организовать процесс, что это не так уж и сложно как может показаться на первый взгляд.
Вы же свой не самый лучший опыт выставляете неким эталоном, чтобы другие какбы равнялись. По крайней мере я так понял посыл статьи.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Если заказчик — редакция