Как стать автором
Обновить

Комментарии 31

Попробуйте применять шире, не только в команде стартапа. Это частая проблема любых взаимоотношений. И почувствуете как они улучшаются и с семьей и с друзьями. И настанет мир во всем мире…
:) Спасибо! Начнем с малого. А потом доберемся и до мира во всем мире
Я считаю что это тоже не корень проблемы, у Вас на этом все не закончится и мир во всем мире не настанет.

Мое ИМХО
У Вас либо нет тимлида, либо у Вас очень плохой тимлид, раздолбай. Хороший тимлид всегда сможет правильно понять дизайнера, проектировщика и уже в простом виде отдать своей команде задачи, так сказать на своем языке, потому что программист может отлично писать код, но он ничерта Ваш язык не понимает, более того он будет изо всех сил стараться понять, но через какое то время забьет, просто кому то это дано, кому то нет, а кто то вообще не хочет таким заниматься.

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

Так же все это блюдо надо в обязательном порядке подавать в виде скрума(scrum).
Он поможет сплотить 2 команды

В общем тимлид это контроллер для команды программистов и человеко понятный интерфейс для внешнего мира

Так же я Вам настоятельно рекомендую прочитать книгу deadline Тома Демарко
в виде чего, извините? скрум, бус, рун, Крум?

По теме, если у вас наемные работники, то ставьте им полную задачу. Если партнеры в стартапе, то относитесь как к партнерам, а не исполнителям. Начинается-то все так: «Эй, ***, хватит пахать на дядю, забабахаем свой проект и станем миллионерами! Только ты все сделай, переделай, отладь и почини, а потом дам тебе премию зарплату, а может и полторы!» А потом зачастую «Вы занимались не работой, а переделыванием, потому что не угадали мои мысли!»
Сори. Я просто хотел Вам ответить и увлекся, надо было отдельным комментом писать
>>> Почему программист соглашается делать то, что не понял или не одобряет? Потому, что: привык работать по ТЗ; ленится думать; боится показаться глупым; не хочет перечить; считает, что «начальник знает лучше»; не хочет брать на себя ответственность; встал в позицию героя а-ля «вот опять придумала ересь, а мне делать»… нужное подчеркнуть.

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

— КАКОГО #%$$%^ НЕ РАБОТАЕТ УУУ????777?777
У нас это называлось экстремальным программированием и код «должен быть в постоянном состоянии рефакторинга».
Agile он такой…
Соглашается по нескольким причинам — устал спорить и доказывать свою точку зрения, к примеру. Или его понимание поставленной задачи разница с понимаем тем, кто ее поставил.

ИМХО самая большая проблема разработки приложений (и не только в стартапах) — отсутствие грамотного продумывания архитектуры системы, что Вы и подтвердили — нет четкого ТЗ. Работаем работу, программируем, а там посмотрим. В результате и получается абы что. А если это не стартап, а активно работающая компания, где все надо сделать вчера, то результат еще плачевнее, ибо начальство прессует непостартаповски :)
Скажите, а как вы думаете, почему к мнению программиста часто не прислушиваются? Вроде как, все от этого в итоге страдают. Хочу собрать мнения, причем и той, и другой стороны.
Чтобы к мнению программиста (или любого другого человека) прислушались, это мнение нужно уметь правильно подать. А это требует иных компетенций, чем есть у большинства программистов. Поэтому Вам и написали выше про тимлида — это тот человек, который сочетает в себе необходимые качества.
А потом вы еще 4 раза спросите «почему»?

Смотрите, у вас вроде как в статье посыл — «не вините программистов», а в итоге все выкладки приводят к тому что они и «виноваты», в частности потому что не думают за других. Программист он на то и программист, чтобы программировать, воплощать идею в код. Чтобы оценивать идею, надо тогда программистов называть не программистами, а как-то иначе. Например, для начала, можно даже разработчиками (системы). Тогда и мнение будет ценнее. Возможно. Кстати есть практика, которая если и не поощряет возврат задач, то как минимум предусматривает — канбан называется.

Более того. Такие же претензии можно предъявить и к тестированию, и к менеджеру, и даже к клиенту («а чего он в поддержку предложение не написал, молча ушел и все?»). Хотя начинать стоит с дизайнера системы конечно (или кто там его роль выполняет — гейм-дизайнер, проектировщик).

Вот смотрите. ТЗ бывают разные. Бывают и полезные. Называются прототипами. Не теми прототипами, которые потом становятся основой продукта, а теми, которые не переиспользуются в качестве основы для будущего продукта. Это могут быть и макеты. У вас есть же список фич? Это уже почти ТЗ. Вобщем мой ответ на все ваши почему — никто не следит за непротиворечивостью требований и их приоритетами.
Я вам отвечу так: потому что, как правило, никто не хочет вникать в техническую сторону вопроса. Ниже есть очень хороший комментарий про «приклей звезду». Обычно именно так всё и происходит. Но при этом арт-директор и прочие дизайнеры уверены в чём угодно — в том, что программист ленив, боится показаться глупым, не хочет перечить и т.п., кроме реальной причины. А реальная причина заключается в том, что изначально никто не продумал архитектуру как следует (чаще всего потому, что в постановке ТЗ собственно программист и не участвовал). Прототипы приложения (на которых можно отработать юзабилити, почувствовать как оно будет выглядеть, наконец узнать то ли это, что хотел клиент) тоже никто не считает нужным делать, уж не знаю почему, дорого наверно, или времени нет.

Вы пишете: "… Всплывают неоправданные ограничения из разряда «если здесь сделать так, где-то там сломается нужная штука». Вот объясните, почему вы решили, что эти ограничения неоправданные?

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

Самое печальное, что после *цатой тупой задачи, программист перестаёт спорить и что-то доказывать-объяснять, т.к. бесполезно, и начинает тупо делать что скажут. Отношение его, к тому что он делает, при этом соответствующее.
Потом он и вовсе уходит (увольняется), т.к. ему надоело заниматься реализацией тупых идей, переделывая одно и то-же по нескольку раз, видя как его код в очередной раз летит в /dev/null.
Проблема ещё и в том что обычно (не всегда, но обычно), решающее слово за человеком который мало понимает в том как по факту работает разрабатываемая система. Не на уровне «мы нажмём тут и вон там выпадет меню», а на уровне «эвентов», структуры данных, используемых технологий и т.д.

В итоге когда программисту говорят — а вот тут приклей звезду! — все вокруг думают что отличие того что есть от того что будет «звезда». Программист же видит как в стройный каркас здания которое он так усердно планировал и собирал вклинивается какая та «звезда» которая полностью противоречит имеющейся логике и структуре. И он бы рад перестроить всё с учётом этой непонятной «звезды» так что бы и она имела право на жизнь. Более того, он уже придумал как сделать так что бы в будущем можно было втыкать эти звёзды куда попало! Но звезда как всегда нужна вчера! И бедняга программист должен собственноручно увечить своё детище.

В итоге, большинство проектов (их кодовая база) выглядят как нагромождение костылей.
Разработчик и дизайнер веб приложений не может быть не программистом, потому что веб страницы состоят из кода. Ему надо понимать, какие он задачи ставит. Так что тот, кто принимает решения, определенно тоже программист.
У нас вообще случай был. Пришёл заказ на установку. Заказчик выслал ТЗ.
В ТЗ был смутно описан алгоритм работы шкафа автоматики. Стали звонить и выяснять подробности.
Но оказывается, заказчик сам ещё не знает, что он хочет от шкафа. Сейчас ему нужно только железо, а по программе «пусть при пуске загорается лампочка „Работа“, пока достаточно, потом приедете и будем разбираться в алгоритме»))
Мне кажется или все можно свести к двум простым тезисам:
1) Максимально вытягивать информацию из клиента до начала работы и дотошно расписывать каждый шаг, скрепляя все договором.
2) Оплачивать работникам труд и время сверх плана и всегда думать, чтобы не делать бессмысленной работы.
1) Не всегда есть клиент, из которого можно вытянуть всю информацию. А если даже есть, то он может не представлять себе четко задачу. Ни разу не видела клиента, который бы предоставил исчерпывающее описание будущего проекта :) А если вы создаете стартап, то сами не представляете, как и что делать. Приходится пробираться на ощупь, не растеряв по дороге ценнейших программистов.

2) Полностью поддерживаю!
если из клиента все вытягивать приходится по крупицам, то с ним однозначно не стоит работать, как правило это часто заканчивается плохо, надо уметь отказываться от клиента.

Если клиент сам не знает что хочет, то ему надо будет в этом обязательно помочь

Если Вы кругами ходите с клиентом и не можете с ним придти к какой то цели и общему пониманию, то Вам надо поучиться переговорам
Так если он не представляет что хочет, вы как работать начинаете, наугад?
Откройте для себя Scrum
Присоединюсь к мнению. Причем не обязательно Scrum. Откройте для себя какую-то методологию. В большинстве из них есть решения для типовых проблем. Например, в упомянутом Scrum это этап оценки. Проведите обсуждения требований, оцените их трудоемкость, прикиньте как это будет тестироваться. Разрешиться очень большое количество вопросов как со стороны разработчиков/дизайнеров, так и со стороны аналитиков/руководителей. После итерации проведите ретроспективу, посмотрите что получилось, что нет. Определите как улучшить процесс разработки. И, да, еще раз, это применяется не только в Scrum, но и в других методологиях. Например, PDCA вообще можно применять при любой методологии.
Проблема в непроработанности и непродуманности ТЗ.
Проще всего её решить, разрабатывая ТЗ одновременно с дизайнером и программистом.
И прежде, чем что-то делать, каждый расскажет, как он это понял и какие есть дополнительные мысли на этот счет.
Спорщики — неудобные люди для начальства, таких не любят, поэтому большинство смирилось и старается не высовываться, кому нужны конфликты? «Мне сказали, я сделал, зарплату получил и хорошо» — вот так думает наш среднестатистический современник. Такое отношение освобождает вашего программиста от ответственности и головной боли, переживаний за то, что кто-то его работу ставит на костыль. «Спрячь сайдбар для одной страницы» — ну разве это не странная идея? Придет ли подобное в голову программисту? Вот он вас и не понял. Почему надо прятать этот сайдбар для одной страницы? Задайте себе этот вопрос. Может быть в будущем у вас появится вторая подобная страница, для которой вы захотите спрятать этот сайдбар? Ну и так далее, по вашей книге!
Вы двигаетесь в правильном направлении — чем точнее описана задача, тем меньше багов будет в последствии и тем меньше нужно будет переделывать.
На основании своего опыта могу сказать, что вам все же надо стремиться к тому, чтобы писать описание к задачам, причем писать его с достаточной степенью детализации. Я считаю, что в вашем случае пробема в «ТЗ устареет еще раньше, чем будет написано» — учитесь писать ТЗ быстро, иначе будете больше времени тратить на правку багов и доработки, чем на новый функционал. Перед распределением задач по разработчикам обязательно обсуждайте задачи с тимлидом, чтобы он мог дополнить это самое ТЗ (Тим лид в свою очередь может привлекать разработчиков, ответственных за тот или иной кусок системы). При передече задачи давайте прочесть ТЗ и обсуждайте детали реализации с исполнителем, дабы убедиться что он все понял и чтобы у него была возможность задать вопрос.

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

Был и в стартапе с недельными/двухнедельными спринтами, где было 2 команды. В нашей команде задачи давались хорошо (достаточно) описанными и проработанными, и переделывать что-то или менять в процессе ничего особо не приходилось. Багов конечно тоже было много, но они были следствием говнокода, доставшегося от начавших проект людей.

В другой команде задачи давались так, что программистам приходилось самим разбираться что и как делать — итог был весьма печален — чуть ли не больше половины времени уходило на правку багов и доработки того, что работает не так, как надо. Как-то раз в нашу команду пришла «срочная» не маленькая задача, но она была плохо проработана, требования менялись на пути, были критичные ошибки в описании workflow по задаче. Скажу, что кроме намного большего количества багов, задача фактически потратила дорогое время кучи народа, только потому, что изначально PM не правильно понял workflow.
Хорошо хоть плетью не бьют…

Пару раз сталкивался с формулировкой — такая идея была, но программиста, такие сякие все профукали.
Или вот еще из опыта, нужно СРОЧНО запилить анимированую анимацию (как выяснилось потом это был флеш на андроиде), за 100 рублей и 15 минут.

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

В общем если хотите чтобы программисты делали хороший продукт, нужно выдвигать разумные требования и немного знать матчасть, а если не знаете то хотя бы иногда прислушиваться к тем кто знает.
Основная проблема, из-за которой возникают все остальные — нужно уметь делегировать зоны ответственности между участниками команды. Если каждый будет понимать, за что он отвечает, как его работа влияет на работу остальных участников команды, и что между ними должна быть обратная связь — многие проблемы будут отпадать сами. Также, весьма необходимо наличие тимлида, человека, который был бы связующим звеном между непосредственными исполнителями задач в команде. Ну и, само собой, нужно пытаться разбивать итерации в разработке на более мелкие этапы, и по окончанию каждой итерации смотреть, что в итоге получается, чтобы вовремя остановить процесс работы в неверном направлении (если так происходит).
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории