Итак, наболело.
Суть текста.
В цепочке клиент — манагер — дизайнер — програмер каждый может накосячить, при чём чем раньше это происходит, тем сложнее все исправлять в будущем. При этом важно отметить, что пусть виноват кто-то другой в этой цепочке, но исправлять все придется именно програмерам, от чего они не испытывают обычно особого удовольствия. И все становится совсем плохо, когда в этой цепочке по сути на результат всем наплевать.
И это нужно исправлять. Срочно. Тыкать носом, не обижаться, сквозь слезы, но исправлять.
Еще немного сути.
Имеем небольшую фирму или цепочку фриланса, как например в моем случае. Я делаю обычно виджеты и небольшие сайтики на флэше. Я пишу о том, что знаю и о чем неоднократно уже говорилось. Таких как я множество и все мы часто сталкиваемся с описанными проблемами. Где-то цепочка другая и свои проблемы, их я здесь не касаюсь.
Собственно, текст.
Что значит наплевать? Кушать хочется всем, поэтому работа будет сделана, но сделана чтобы просто отстали. Так получаются все посредственные сайты, которые хоть и нравятся клиенту, но представляют собой то еще убожество и при этом влекут кучу геморроя в будущем. Печально, когда за такие творения их создателям совершенно не стыдно.
Забавно, но даже работая вместе несколько лет, люди часто не особо представляют что и как делают их коллеги. Им это не нужно. Им плевать. Отсюда все проблемы. Проще привести пару примеров, чем пытаться абстрактно описать ситуацию.
Есть манагер, он говорит клиенту что ему нужно, тот соглашается. Проект вроде бы простой. Составляется небольшое описание, собираются какие-то дополнительные материалы. Но манагер не очень знаком с кухней программирования, ему лень и немного плевать. Поэтому дизайнеру и програмеру приходят не то что неполные данные, а неверные и с кучей мест, которые «и так понятны». Манагер не задумывается о том, что он-то очень весомое звено во всей цепочке, ибо его косяки обрастут косяками как снежный ком, а исправлять все придется програмерам. И не важно будет кто и когда накосячил. У програмера задача вербальное описание работы программы перевести в код, который что-то делает максимально приближенное к этому описанию. При этом от небольших нюансов описания может зависеть чрезвычайно много, например, выбранная архитектура приложения, которую потом изменить будет весьма затратно.
Итак, манагер не знает как я (програмер) работаю и смутно представляет что мне нужно. Вы спросите нафига он такой нужен? Ну, вот такие они у нас в большинстве случаев. Передавая описание дизайнеру, он сам упускает кучу ключевых моментов, а дизайнер в свою очередь упускает еще кучу важного. Потому что, он тоже не особо в курсе програмерских дел, ему главное набросать рисуночек, а после нас хоть потоп.
Часто люди, которые могут сделать красивую картинку, совершенно не приспособлены создавать красивые и при этом функциональные дизайны. Ведь его работа позже должна быть переведена в интерфейс. Тут целиком и полностью видно мастерство дизайнера, точнее его отсутствие. Часто он даже не задумывается, что кроме красивой картинки и ее исходника в PSD (который, надо сказать, будет читаться посторонним человеком, а куча слоев Layer 1, Layer 2, Layer 543 его никак не обрадуют) програмеру понадобится еще куча вещей. Например состояния кнопок, отрисованные невидимые анимированные детали итд. Сколько раз мне приходилось дорисовывать такую фигню. И что забавно, это было быстрее, чем просить дизайнера нарисовать отсутствующие детали. Пока он прочитает письмо, сходит на обед, выкроит время где-нибудь вечерком и пришлет результат завтра после обеда. Но, разумеется, при этом никто не делает в это время мою кодерскую работу пока я правлю дизайнерскую работу.
Здесь видно, что дизайнер не знает что нужно програмеру, а манагер в свою очередь дизайнеру об этом не говорит, потому что ему лень или он сам не в курсе. Дизайнер, конечно же, рисует только то, что просили, и не полпикселя больше.
Спросите а где был програмер в начале? Почему он не сказал точно что ему нужно? Очень, очень часто програмер вообще узнает о том, что ему делать, когда уже присылают готовый дизайн и небольшое описание к нему. У вас не так? Тогда мы идем к вам (8 Суть не в этом.
Я пытаюсь данным текстом высказать основную идею — народ не в курсе и народу плевать. Часто плевать и мне, но я последнее звено. Часто мне лень, я делаю хаками вещи при этом основываясь на документации и дизайне, потом оказывается, что «имелось в виду другое» и эти хаки мне заменять нормальной реализацией с переписыванием по пути половину кода из-за таких вот «интуитивно понятных вещей».
Надо тыкать носом!
Надо! Носом! Сквозь слезы. Не смотря на обиды. Я, кстати, сталкивался с товарищами, которых оскорбляли мои претензии. С товарищами, которые так упорно и не исправлялись что бы я не делал. Эта проблема очень важна. Она корень множества бед. Когда босс сидит в офисе и думает что за фигня, вроде бы все работают и делают свое дело, но получается дерьмецо, он не знает, что его сотрудникам плевать и на работу и на остальных.
Позитивный пример.
Но не все так грустно. Я за свою жизнь работал в куче таких цепочек. И были цепочки очень даже позитивные. Манагеры, которые знали кухню, дизайнеры, которые присылали нарезанные прозрачные картинки со всеми нужными состояниями, анимацией и описанием. Были и в моей памяти идеальные проекты, которые часто портили сами заказчики, но об этом в другой раз.
С такими людьми приятно работать, по цепочке передается настроение профессионализма и ненаплевательства.
Вопрос.
Как бороться?
В последний раз я девочке дизайнеру в вежливой форме указал что нужно и как нужно… Она обиделась и разрыдалась.
После часа чата вчера, сегодня все участники опять ведут себя по старому и ничего не меняется.
Как изменить ситуацию в корне?
Програмер не должен контролировать весь процесс только для того, чтобы получить все нужные ему материалы. Тогда он становится уже манагером, и при этом сохраняет свои програмерские обязанности и сроки. От програмера требуется информация о возможности и сроках. Когда люди не в курсе что и как делаешь ты, с ними ужасно сложно работать, а в итоге крайним оказываюсь именно я...
Суть текста.
В цепочке клиент — манагер — дизайнер — програмер каждый может накосячить, при чём чем раньше это происходит, тем сложнее все исправлять в будущем. При этом важно отметить, что пусть виноват кто-то другой в этой цепочке, но исправлять все придется именно програмерам, от чего они не испытывают обычно особого удовольствия. И все становится совсем плохо, когда в этой цепочке по сути на результат всем наплевать.
И это нужно исправлять. Срочно. Тыкать носом, не обижаться, сквозь слезы, но исправлять.
Еще немного сути.
Имеем небольшую фирму или цепочку фриланса, как например в моем случае. Я делаю обычно виджеты и небольшие сайтики на флэше. Я пишу о том, что знаю и о чем неоднократно уже говорилось. Таких как я множество и все мы часто сталкиваемся с описанными проблемами. Где-то цепочка другая и свои проблемы, их я здесь не касаюсь.
Собственно, текст.
Что значит наплевать? Кушать хочется всем, поэтому работа будет сделана, но сделана чтобы просто отстали. Так получаются все посредственные сайты, которые хоть и нравятся клиенту, но представляют собой то еще убожество и при этом влекут кучу геморроя в будущем. Печально, когда за такие творения их создателям совершенно не стыдно.
Забавно, но даже работая вместе несколько лет, люди часто не особо представляют что и как делают их коллеги. Им это не нужно. Им плевать. Отсюда все проблемы. Проще привести пару примеров, чем пытаться абстрактно описать ситуацию.
Есть манагер, он говорит клиенту что ему нужно, тот соглашается. Проект вроде бы простой. Составляется небольшое описание, собираются какие-то дополнительные материалы. Но манагер не очень знаком с кухней программирования, ему лень и немного плевать. Поэтому дизайнеру и програмеру приходят не то что неполные данные, а неверные и с кучей мест, которые «и так понятны». Манагер не задумывается о том, что он-то очень весомое звено во всей цепочке, ибо его косяки обрастут косяками как снежный ком, а исправлять все придется програмерам. И не важно будет кто и когда накосячил. У програмера задача вербальное описание работы программы перевести в код, который что-то делает максимально приближенное к этому описанию. При этом от небольших нюансов описания может зависеть чрезвычайно много, например, выбранная архитектура приложения, которую потом изменить будет весьма затратно.
Итак, манагер не знает как я (програмер) работаю и смутно представляет что мне нужно. Вы спросите нафига он такой нужен? Ну, вот такие они у нас в большинстве случаев. Передавая описание дизайнеру, он сам упускает кучу ключевых моментов, а дизайнер в свою очередь упускает еще кучу важного. Потому что, он тоже не особо в курсе програмерских дел, ему главное набросать рисуночек, а после нас хоть потоп.
Часто люди, которые могут сделать красивую картинку, совершенно не приспособлены создавать красивые и при этом функциональные дизайны. Ведь его работа позже должна быть переведена в интерфейс. Тут целиком и полностью видно мастерство дизайнера, точнее его отсутствие. Часто он даже не задумывается, что кроме красивой картинки и ее исходника в PSD (который, надо сказать, будет читаться посторонним человеком, а куча слоев Layer 1, Layer 2, Layer 543 его никак не обрадуют) програмеру понадобится еще куча вещей. Например состояния кнопок, отрисованные невидимые анимированные детали итд. Сколько раз мне приходилось дорисовывать такую фигню. И что забавно, это было быстрее, чем просить дизайнера нарисовать отсутствующие детали. Пока он прочитает письмо, сходит на обед, выкроит время где-нибудь вечерком и пришлет результат завтра после обеда. Но, разумеется, при этом никто не делает в это время мою кодерскую работу пока я правлю дизайнерскую работу.
Здесь видно, что дизайнер не знает что нужно програмеру, а манагер в свою очередь дизайнеру об этом не говорит, потому что ему лень или он сам не в курсе. Дизайнер, конечно же, рисует только то, что просили, и не полпикселя больше.
Спросите а где был програмер в начале? Почему он не сказал точно что ему нужно? Очень, очень часто програмер вообще узнает о том, что ему делать, когда уже присылают готовый дизайн и небольшое описание к нему. У вас не так? Тогда мы идем к вам (8 Суть не в этом.
Я пытаюсь данным текстом высказать основную идею — народ не в курсе и народу плевать. Часто плевать и мне, но я последнее звено. Часто мне лень, я делаю хаками вещи при этом основываясь на документации и дизайне, потом оказывается, что «имелось в виду другое» и эти хаки мне заменять нормальной реализацией с переписыванием по пути половину кода из-за таких вот «интуитивно понятных вещей».
Надо тыкать носом!
Надо! Носом! Сквозь слезы. Не смотря на обиды. Я, кстати, сталкивался с товарищами, которых оскорбляли мои претензии. С товарищами, которые так упорно и не исправлялись что бы я не делал. Эта проблема очень важна. Она корень множества бед. Когда босс сидит в офисе и думает что за фигня, вроде бы все работают и делают свое дело, но получается дерьмецо, он не знает, что его сотрудникам плевать и на работу и на остальных.
Позитивный пример.
Но не все так грустно. Я за свою жизнь работал в куче таких цепочек. И были цепочки очень даже позитивные. Манагеры, которые знали кухню, дизайнеры, которые присылали нарезанные прозрачные картинки со всеми нужными состояниями, анимацией и описанием. Были и в моей памяти идеальные проекты, которые часто портили сами заказчики, но об этом в другой раз.
С такими людьми приятно работать, по цепочке передается настроение профессионализма и ненаплевательства.
Вопрос.
Как бороться?
В последний раз я девочке дизайнеру в вежливой форме указал что нужно и как нужно… Она обиделась и разрыдалась.
После часа чата вчера, сегодня все участники опять ведут себя по старому и ничего не меняется.
Как изменить ситуацию в корне?
Програмер не должен контролировать весь процесс только для того, чтобы получить все нужные ему материалы. Тогда он становится уже манагером, и при этом сохраняет свои програмерские обязанности и сроки. От програмера требуется информация о возможности и сроках. Когда люди не в курсе что и как делаешь ты, с ними ужасно сложно работать, а в итоге крайним оказываюсь именно я...
