Pull to refresh

Comments 19

А теперь замените программистов на строителей, которым редакция заказывает строительство офиса. Пройдет такой подход? Врядли.
Слово «редакция» на слово «заказчик» можно заменить без потери смысла.
Раньше тоже сравнивал создание веб сайтов со строительством зданий. Теперь думаю что это сравнение не совсем корректно. Строительство зданий скорее можно сравнивать с созданием дата-центра или настройкой серверов, ну или созданием веб-движка (CMS). Создание веб-сайта это скорее декорация офиса, расстановка мебели, создание витрины: эти вещи постоянно меняются, а здание (основа) остается.
Это смотря какой сайт вы делаете. С узкоспециализированными сайтами для которых есть ходовые движки (блог, магазин) — да. Это взять тему и разукрсить под заказчика — декорация.
Если вам нужно спроектировать что то уникальное вроде скидочного сайта или узкоспециализированной социальной сети: здесь уже проектирование.
Как и в строительстве: постройка дома это изначально проектирование. Так и здесь все осталось по-прежнему. А если вы принимаете участие в группе, которая занимается декорацией — ведь это не значит, что вся индустрия работает точно так же. Верно?
Что-то вы плохо понимаете про постройку дома. При постройке дома точно так же берётся типовой проект и, максимум, подгоняется под рельеф местности. А дальше только декорации. Разница только в том, что типовую CMS легче скопировать — залил на хостинг, настроил и уже летим. А дом по типовому проекту ещё строить надо.
Опять таки: типовый проект. Конечно, в наши дни типовое можно встретить гораздо чаще, чем не-типовое, на то и время копирования и масштабирования. Но все таки индивидуальные строения делаются и им отводится гораздо больше внимания, да и отдачи они дают гораздо больше. Нетипичные небоскребы в Батуми, например гораздо выше ценятся, чем типичные многоэтажки. Я к тому, что даже не в сайтах, а в комплексных довольно больших проектах, не редко проектирование и оно востребовано. Сложно наверное представить проект Фейсбука развернутый на какой ни будь CMS, ведь так же? Я не спорю, что есть уже CMS реализующие функционал социальной сети, но например проект по бронированию такси через вебсайт — это уже достаточно нетривиальная задача для обычной CMS.
UFO landed and left these words here
Мне всегда нравилась метафора с машинами. Во многих предложениях если заменить «сайт» на «автомобиль», особенности разработки сразу становятся понятны всем.

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

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

А кто это должен делать, как не менеджер? Правильный менеджер — контактирует с заказчиком, разбирается в предметной области, и предоставляет для конкретных разработчиков «хотелки» в нормализованном виде — схемы бизнес-процессов, диаграммы use-case и прочее. В лучшем случае, проработка этого идет вместе с lead-ом. Если менеджер просто бегает между заказчиком и разработчиками, уговаривая каждого пойти на компромисс — грош цена такому менеджеру.
Может пару примеров как были разрулены те или иные ситуации? А то какая-то слишком общая статья.
Описанная вами ситуация с редакцией — это точная копия очень многих малых бизнесов, когда на отдельного менеджера для ведения диалогов с разработчиками просто не выделен бюджет.

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

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

Подстраиваться непременно нужно, ведь мы все живые люди с чувствами и личными убеждениями, но лишь в рамках, строгих рамках ведения проектов.
Прямо как бальзам на душу в плане Вики! Сам сейчас постепенно прихожу к необходимости такие вещи делать. На каких-то проектах организуем такую штуку через Trello, хотя структура, конечно, хромает.
Спасибо за идею GitHub. Нужно будет попробовать.
Одно из преимуществ wiki на GitHub – возможность редактировать файлы локально на компьютере, работая как с репозиторием. Так как менеджеры с терминалом работать не умеют, на помощь приходят настольные приложения для git. В частности, можно скачать GitHub for Mac. Репозиторий с wiki для проекта лежит по адресу git@github.com/username/reponame.wiki.git. То есть к адресу обычного репозитория добавляется суффикс .wiki. Один раз настраиваем, показываем как делать коммиты, кликая вон ту зелёненькую кнопку. И все довольны.
«Перезапускали» недавно небольшое региональное медиа издание. В общих чертах ситуация похожая.

НО, не нужно это преподносить как некую неизбежность, типа если заказчик редакция — даже не пытайтесь.

Аргументы «нет времени» звучат смехотворно — ни у кого никогда нет времени, все заняты, в конце концов ИТ специалистам тоже есть что почитать и пописать. У нас время нашлось.

ТЗ отсутствовало за ненадобностью. Были чёткие цели редизайна, далее были макеты, далее пожелания редакции и внесение небольших изменений в основном в очень специфичные проекты. Когда все понимают «зачем это всё вообще», и главное дизайнер, правок не так уж много. Далее программистам нужно было «натянуть» вёрстку, они решили что тз для этого им ненужно, хотя для выполнения задачи требовались небольшие изменения в структуре данных. Все «а добавьте сюда кнопочку» оставлялись на усмотрение разработчика, либо делалось сразу, либо откладывалось на потом(после редизайна), и необходимость в большей части этих «хотелок» отпала сама собой, через пару недель, когда редакция полностью «въехала» в новые правила публикации материалов.

Все участники очень переживали, что результат не оправдает надежд, долго тянули с выводом в продакшн, смотрели/думали опять смотрели, но в итоге всё прошло достаточно гладко.

И главное сейчас я понимаю, что можно лучше, быстрее проще организовать процесс, что это не так уж и сложно как может показаться на первый взгляд.
Вы же свой не самый лучший опыт выставляете неким эталоном, чтобы другие какбы равнялись. По крайней мере я так понял посыл статьи.
Only those users with full accounts are able to leave comments. Log in, please.