Pull to refresh

Comments 44

В точку! Подписываюсь под каждым словом.
А вы не делайте чужую работу ;) Когда человека заставляют править все его косяки на ХХ раз (в зависимости от человека от раза до десятка) он уже задумывается (и правит) их до того, как они перейдут к следующему по цепочке. Весь косяков и неточностей ни когда не поправить, но типовые ошибки в таких случаях правятся.
на тебе висит дедлайн и ты вынужден эту работу делать
ты крайний
нужно просто не принимать дизайн
даже если 2х пиксельной загогулины нет, тупо берешь и не принимаешь, и пока эта загогулина не появится — не начинаешь делать и не стартуешь отсчет времени
Хотелось бы мне чтобы всё было так просто…
Всё так и просто — описывается перечнем служебных обязанностей специалиста. В моём перечне написано, что я могу не приниматься за работу, пока все материалы, которые мне необходимы не будут предоставлены.
Если каких-то элементов дизайна нет, то об этом ставится в известность руководитель проекта, ну а он в свою очередь будет пинать дизайнера и ответственность уже несут дизайнер и руководитель — либо дизайнер недорисовал, либо руководитель его недопинался.

Ну а совсем в запущенных случаях поднимается вопрос о профпригодности того или иного элемента звена.
девочка-дизайнер в приватной беседе и ярких красках расписывает как злобный программист довел ее до слез и поднимет вопрос о пригодности программиста.
а руководитель проекта на что? пусть он и общается с девочкой-дизайнером. Ну а во-вторых работа это не место для эмоций.
В принципе — я согласен с Вашей позицией. Но мы с Вами не знаем всех деталей ситуации у автора. Соответственно имеет смысл предполагать все возможные варианты событий. А автор, либо люди в близкой ситуации, смогут самостоятельно выбрать для себя наибольшее подходящие им варианты.
Статья немножко отдает нытьем, но самую малость. в целом все верно. ставлю плюс. И тоже поделюсь историей на тему.
Работал я веб-программером в одном проекте. С заказчиком общался фотограф, взявший на себя функции манагера. Сколько он стряс с заказчика, никто не знает. Всю работу по созданию сайта делали мы с дизайнером. При этом плотно с ним общались, он махом доделывал все, о чем я его просил. Я тоже выполнял разные дополнительные исправления по его замечаниям. Работать в паре с ним было удовольствием, чего не скажешь о «манагере». Он общался с заказчиком, по своему трактовал его пожелания, а потом пересказывал дизайнеру и мне. В итоге несколько раз приходилось переписывать большие участки кода, перелопачивать дизайн и т.д. А пообщатся напрямую с заказчиком, чтобы узнать, что же все-таки хочет он, нам не давали — видимо, боялись, что мы оставим манагера не у дел.
В конце концов работа сдана, деньги получены, но мне стыдно за такую поделку, дизайнеру тоже. Мы зареклись работать с этим фото-манагером.
а еще очень часто, просят сделать «вот точно так, как на том сайте, только кнопочки потемнее и шрифт другой...»
а некоторые при этом еще и указывают сколько у тебя эта работа времени займет!
хорошо расписано!
— «У програмера задача вербальное описание работы программы перевести в код, который что-то делает максимально приближенное к этому описанию. При этом от небольших нюансов описания может зависеть чрезвычайно много, например, выбранная архитектура приложения, которую потом изменить будет весьма затратно.»
ЗОЛОТЫЕ СЛОВА! Сколько раз я это пытался объяснить заказчикам, но слов подходящих не мог найти!
если ты не можешь что-то объяснить заказчику, значит этого чего-то не существует :-)
Требуйте от заказчика ТЗ
Работайте только по ТЗ
Никаких изменений по ТЗ во время работы не принимайте
я же специально писал про цепочку
требовать ТЗ — это когда сам себе манагер
в описанных ситуациях это работа манагера. манагер лажает, что с кого мне требовать?
програмер отдувается в итоге за всех.
Нет, манагер не умеет делать ТЗ
ТЗ делают отдельные люди
тут спорный момент, четко по тз нельзя работать, так-же само как и нельзя составить 100% точное тз, всегда кто-то что-то упустит
вообще, вполне нормлаьная норма когда исполнитель делает на 7-10% больше, чем указанно в тз (больше не значит что он делает какой-то функционал — подправляет, переделывает то, что было упущенно или не так спроектированно)
тут важно знать грань этих 7-10%, и момент, когда заказчику необходимо отказать, когда он еще не привык (не вошел во вкус того, что ему делают «больше») и когда эти 7-10 абстрактных % покрыты
Забудьте о «манагерах». Если вы работаете с «манагером» не будет вам счастья.
Работать надо с менеджерами проекта или руководителями проекта. В чем же разница?

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

Менеджер (руководитель) проекта: решение задачи клиента через визуальную часть проекта (дизайнер, копирайтер) и программную часть проекта (программист, технолог, верстальщик).

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

Кстати как показывает практика:

Если у вас плохой менеджер и дизайнер, скорее всего вы плохой программист
С последней мыслью не согласен.
Менеджеров, как и родителей, не выбирают. А количество хороших менеждеров проектов исчезающе мало. Такие люди вообще на вес золота. Как собственно и любые профессионалы.
Вобщем согласен вами, поэтому в последнем предложении есть — «скорее всего». И в 90% случаев это так и есть, просто человек этого не осознает…

Ты хороший программист? Отправляй резюме в яндекс, гугл, топ 20 web студий и работай с профессионалами. Зачем мучиться с неумехами и тратить свое драгоценное время на обучение да еще и возмущаться этому?
Идти на работу в Яндекс или Гугл — это конечно хорошо, но во-первых это путь не для всех (ну не могут 100% хороших программистов работать в Гугле или Яндексе), а во-вторых хочется что-то поменять в той отрасли, где ты работаешь. Мне нравится делать сайты, проектировать сложные системы и нравится делать это там, где я сейчас работаю. Остается только подтягивать остальных участников цепочки до своего уровня. Это сложный, но пожалуй самый правильный путь.
А бежать в лучшую жизнь, просто потому что в текущей трудно — это путь в никуда.
Вы текст-то читали?
В цепочке нет менеджера проекта, который был бы выходцем из программиста.
И да, я плохой недовольный программист.
СМ выше.

Кстати судя по дате рождения указанной в твоем (думаю тут можно на ты) профиле, мы с тобой почти ровесники, так что твой ход мыслей мне непонятен, он слишком не зрел и это странно…
если у вас плохой компьютер, скорее всего, вы плохой дизайнер.
если у вас плохой, скорее всего, вы плохой.
UFO just landed and posted this here
абсолютно верно, если соглашаться нести риски по нему. Но это обычно легче
Я смотрела два года на ситуацию со стороны менеджера. И меня злило отношение программиста и дизайнера, как вас злит отношение менеджера.
Менеджер общается с заказчиков, посему в случае не стыковок, багов, недочетов — все шишки сыплются на менеджера, менеджер оправдывается и ищет пути решения. Дизайнер и программист при этом остаются за ширмой, у них все хорошо и спокойно.

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

У вас программер не предлагает ничего, чтобы могло облегчить труд всем, к примеру что-то по ТЗ? Так это ваша задача его мотивировать на то, чтобы он сам оптимизировал собственный труд.

Что злиться-то?

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

ЗЫ: Сейчас совмещаю в себе и менеджера, и программиста, и QA, и общение с заказчиком почти напрямую. Крайне тяжело. Крайне тяжело постоянно говорить себе: «это твоя обязанность». Но зато интересно
> Ну и как писали выше, если есть возможность можно совместить программера и менеджера
Так говорят люди ничего ен сображающие в управлении проектами. У манагеров и програмеров разные цели.
У вас есть два варианта:
1. Не работать с такими людьми. Кардинальный способ, но крайне действенный. Собственный труд и себя надо уважать.
Дизайнер не принимает критику? Лесом ее, дизайнеров сейчас огромное кол-во на рынке труда. И толковых много.
Менеджер не понимает процесс разработки? Ищи адекватнее начальство.

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

Объяснить менеджеру почему важно потратить больше времени на ТЗ и на хороший дизайн *до* согласования с заказчиком проще простого — это очень сильно экономит время.
Кстати, писать ТЗ менеджер не должен. Только если он «в теме» и берет на себя эту обязанность.

А вообще, действительно похоже на нытье. Вы недовольны ситуацией, но не пытаетесь ничего менять. Начинать надо с себя: понять почему дизайнер на вас обиделась, почему менеджер не слушает, а делает по-своему и тп…
Список людей, которым на всё плевать бесконечен!

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

Учись на их ошибках, расти сам, и переходи на лучшие должности. Нечего адекватному человеку засиживаться в гнилых коллективах.
Успехов.
Про ответственность… Расскажите, как можно дорасти до кого-нить выше работника самого низшего звена не беря на себя ответственность?
обычно параллельно с этим приходит понимание и опыт перекладывания и распределения ее на других :)
Окей «зря берешь лишнюю ответственность на себя». Лишняя, потому что за постановку задачи, графические элементы — отвечает не программист, а соответствующие люди. Если человек подписывается не под свои дела — то на него будут сваливать все больше. Ездят на том, кто дает на себе ездить.
С другой стороны — я за проактивность: когда ты проявляешь инициативу не только в своей области и тебе за это воздается. Но против существующих практик: сваливать все на разрабов, и потом во всем винить их.
«Я не буду это верстать, потому что дизайнер нарисовал непотребную херню»
«Я (не) буду делать это так, потому что пострадает usability»

Подчиненному, пусть и одной должности: «сделай так, если что — я сказал»

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

Верстальщика не должно волновать, что там нарисовал дизайнер. Это не его работа. Точно так же, как программиста не должно волновать то, что где-то там кнопочки не подсвечиваются.

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

Представим стройку, куда привезли гнилые строй материалы. Бригада взяла и сделала. Ей же сказали сделать.

Человек отличается от обезьяны тем, что думает. Так вот надо это использовать, а не просто сделать что сказали.
Верстальщик не может оценивать работу дизайнера. Точно так же дизайнер не может посмотреть на код и сказать: «это говно, надо всё переделать».

Контроль качества должен быть от руководства, от менеджера проекта и т.д., но никак не от верстальщика. Если верстальщик считает, что что-то в дизайне не так — можно предложить руководству переделать.

А если позиция «Я не буду это верстать, потому что дизайнер нарисовал непотребную херню» — гнать в три шеи. У нас один такой был.
«Сейчас рядом со мной сидят два чела, которые в последней сессии получили новые ранги, а человека, который вытянул их проекты — сокращают.» — как думаете, если он настоящий профи, то устроит себе отпуск и будет работать в лучшей компании уже через час после увольнения
Как настоящий профи он сейчас делает собственные проекты. Поиск лучшей, чем своя собственная, компании — для профи это план Б.
У нас работал HTML-кодер, которому было наплевать. Полностью. Работа не шла, постоянно были ссоры внутри «цепочки». Через месяц мы уволили этого верстальщика, и всё стало замечательно :-)
Старая как мир история про Рака, Лебедя и Щуку. Каждый тянет телегу на себя. Вот я молодец, а они к… лы неприятные.

Как мне кажется вам нужно обратить внимание на методологию SCRUM ( www.osp.ru/os/2007/04/4220063/ ).
Мне в моей практике управления рабочими группами из 4-10 человек данная методологию очень помогла.
я уже смирился с такими проблеммами как неполнота задачи.
решил так — как программер я делаю все от меня возможное, я отвечаю за код, и пусть мой код будет правильным и без багов.
я делаю свою работу, менеджер свою. Есть у меня вопросы — задаю, иногда сам придумываю. Ненравится клиенту — переделаем за его деньги, но такое редко получается. ТОгда и работа программера становится не ремеслом.
Просто неполучится все описать документацией, да и к чему столько времени на нее убивать. Конечно же ТЗ нужно и оно есть, но оно, как правило, не отражает полной картины.
Sign up to leave a comment.

Articles