Comments 29
Крайне интересно было почитать. Причем, после прочтения многие вещи становятся понятны, с которыми сталкивался когда-то в ходе работы. И сразу возникает желание всю эту статью распечатать и повесить в каждом офисе)) Жаль, что мало кто из руководства знает хотя бы половину из перечисленных пунктов. Разработчики тоже не идеальны, но в том и фишка, что никто не идеален, но каждый знает, как совместными и правильными усилиями добиться успеха для проекта и компании в целом. Статейку в избранное, спасибо!
По данным IBM Systems Magazine, 54% неудач IT-проектов связаны с управлением и лишь 3% имеют отношение к техническим проблемам.
Эти бы слова, да в уши начальству :)
Ну и по остальным пунткам тоже плюс. :)
П.С.
Эта статья — тот редкий случай, когда я с ней согласен, а не язвлю с тупости. :)
Есть отличний анализ типов разработчиков в книге ""/«Как пасти котов» Дж. Рейнвотера.
На Хабре был пост о ней https://habrahabr.ru/company/piter/blog/265389/
Книга старая, но всячески рекомендую к прочетнию тем, кто руководит программистами.
Отдельная благодарность за ссылку на статью в IBM Systems Magazine.
К сожалению, даже в ней не написано, почему проваливаются оставшиеся 43% проектов.
На Хабре был пост о ней https://habrahabr.ru/company/piter/blog/265389/
Книга старая, но всячески рекомендую к прочетнию тем, кто руководит программистами.
Отдельная благодарность за ссылку на статью в IBM Systems Magazine.
К сожалению, даже в ней не написано, почему проваливаются оставшиеся 43% проектов.
Есть интересный пример из жизни, очень бы хотелось комментариев:
В режиме стартапа, без четких требований и описаний API был реализован на коленке некий проект, включающий серверный код, клиентское веб-приложение да еще и мобильное приложение с отдельной функциональностью. Все это интегрировано с неким коммерческим веб-сервисом (который тоже в режиме стартапа). Делалось все на энтузиазме небольшой команды. В итоге всё взлетело и стало работать, но код во всех трёх блоках был конечно ужасен. План был таков, что после релиза MVP и пилотирования будут понятны пожелания клиентов из которых можно будет понять планы развития и спроектировать подходящую архитектуру.
После двух месяцев пилотирования оказалось, что бэкэнд, написанный на PHP в самом ужасном стиле в общем-то прекрасно работает и не требует доработок. Тем не менее, мнения участников команды разделились — одни утверждают что именно бэкенд нужно переписать с нуля качественно, т.к. в будущем он может создать проблемы (и это правда). Другие считают, что т.к. в перспективе задач для бэкенда нет, его лучше оставить как есть, сосредоточив ресурсы на фронте и мобильном приложении, к которым уже набрался приличный стек пожеланий клиентов.
Личное имхо. Бек — это основа работы сервиса в целом, а также основа для функционирования мобильных приложений. Качество всего сервиса и услуг, которые он предоставляет, основано именно на бекенде. Если вы не планируете оставлять проект на том же уровне, что и сейчас, а хотите в будущем его развивать (а это нормально, любой остановившийся в развитии проект быстро теряет клиентов), — то вам нужен бекенд, который можно будет легко расширять и сопровождать. Поэтому в него стоит вложить время и усилия, причем лучше это сделать именно сейчас, пока нет каких-то тяжелых проблем, срочных задач и так далее, то есть можно относительно спокойно все перепахать, не трогая при этом рабочую версию сервера. А мобильные разработчики вполне себе могут параллельно пилить свои платформы на существующем серваке, им никто не мешает. Если есть нехватка ресурсов — я бы поправил критичные проблемы на фронте (если таковые имеются, т.е. не пожелания, а именно проблемы, мешающие использованию приложения, самые-самые яркие жалобы клиентов), а потом бросил силы на приведение бекенда в состояние «сияет всеми цветами радуги». Потом уже и мобильные подтянуть.
Если коротенько — важно иметь фундамент. Бек — это фундамент для мобильно-ориентированного сервиса. Без фундамента вы в любом случае, рано или поздно, но придете к его модификации, и вот тогда плохо будет всем. И серверным разрабам, и мобильным. И компании в целом, естественно.
Если коротенько — важно иметь фундамент. Бек — это фундамент для мобильно-ориентированного сервиса. Без фундамента вы в любом случае, рано или поздно, но придете к его модификации, и вот тогда плохо будет всем. И серверным разрабам, и мобильным. И компании в целом, естественно.
то вам нужен бекенд, который будет легко расширять и сопровождать.
В том и проблема, что на текущем этапе нет задач, требующих доработок бэкенда. Соответственно можно только догадываться о направлении его расширения. А значит тратить ресурсы на гипотезы, а не на факты.
Если есть нехватка ресурсов — я бы поправил критичные проблемы на фронте (если таковые имеются, т.е. не пожелания, а именно проблемы, мешающие использованию приложения, самые-самые яркие жалобы клиентов)
Да, но у потенциальных клиентов есть конкретные пожелания по функциональности фронта и мобильного приложения. Без их реализации они не станут клиентами. А без клиентов cashflow проекта просто не позволит переключиться из режима разработки на энтузиазме в режим нормального экономически выгодного производства.
Грамотные специалисты по бекенду (и по мобильным аппам тоже) могут превратить код из «помойки» в аккуратное творение, готовое хотя бы к сопровождению, а также к небольшому расширению. Если специалист говорит, что код ужасен (судя по вашему посту выше), но при этом не представляет, как его модифицировать, если нет «конкретных задач», — то, возможно, стоит поискать более квалифицированного специалиста, хотя бы и со стороны, как консультанта (хотя сам не одобряю консультантов, но ситуации разные бывают). Никто не говорит, кстати, что нужно пытаться придумать несуществующие задачи и сделать из бекенда этакого семиголового монстра, который может все и ничего одновременно. Речь всего лишь о том, что нужно отшлифовать, перекрасить и отполировать то, что и так работает, но находится в плачевном состоянии.
Но в целом тут уже вопрос к вам как к руководителю. Нужно расставить приоритеты, выяснить, какие задачи по мобилкам тянут приложение вниз (если таковые имеются), и какую часть имеющихся ресурсов вы готовы направить в фундамент, а какую — в удовлетворение клиентов. Полностью довольными клиенты не будут никогда, всегда есть некий неплохой процент тех, что что-то предлагает или хочет изменить, это нормально. Важно лишь выделить оттуда действительно стоящие вещи.
Но в целом тут уже вопрос к вам как к руководителю. Нужно расставить приоритеты, выяснить, какие задачи по мобилкам тянут приложение вниз (если таковые имеются), и какую часть имеющихся ресурсов вы готовы направить в фундамент, а какую — в удовлетворение клиентов. Полностью довольными клиенты не будут никогда, всегда есть некий неплохой процент тех, что что-то предлагает или хочет изменить, это нормально. Важно лишь выделить оттуда действительно стоящие вещи.
Грамотные специалисты по бекенду
А их нет у нас. Есть только начинающие, постепенно растущие.
стоит поискать более квалифицированного специалиста
На энтузиазме? Платить пока нечем. Пробовать искать за долю — значит двигать все доли в команде. Очень непростая задача, есть реальный риск развалить команду.
Полностью довольными клиенты не будут никогда, всегда есть некий неплохой процент тех, что что-то предлагает или хочет изменить, это нормально. Важно лишь выделить оттуда действительно стоящие вещи.
Тут как раз всё очень просто. Есть структурированный список "хотелок", есть количество желающих клиентов по каждому пункту, отсюда легко определить приоритеты.
Смотрите сами, опять-таки, это вопрос исключительно к вам как к руководству. Бизнес «без оплаты, на энтузиазме» — это всегда двойной риск. Сам стартап — это уже риск, а если у стартапа нет денег — это уже совсем рискованно, потому что все держится именно на энтузиазме. А энтузиазм — штука переменчивая. Как минимум, стоит сосредоточиться на том, чтобы люди не потеряли веру в проект, но и вся ваша клиентура не разбежалась, а также чтобы стартап не уперся в стенку, когда столкнется с необходимостью внести изменения в код, который невозможно модифицировать. Этот баланс крайне сложно соблюдать, и редко это получается на 100%, но в этом и состоит прелесть и одновременно сложность работы руководителя. Думайте, что для вас лучше, куда распределять ресурсы и куда лучше вести компанию. Тут вряд ли мнение со стороны вам чем-то поможет, особенно когда неизвестны никакие внутренние детали процессов, протекающих в компании.
> https://vk.com/video3981242_168222671?t=47m20s
Задачи всегда есть. Да хоть нагрузочное тестирование, рефакторинг на скорость, на отдачу веб-страниц, логирование, алерты о дауне серваков и тд.
Ошибся с копипастой цитаты:
В том и проблема, что на текущем этапе нет задач, требующих доработок бэкенда
Это всё стОит ресурсов, есть ли экономический смысл на текущем этапе?
У вас вопросы, по которым вы должны дать ответ самому себе.
Спрашиваете что делать — удовлетворить клиента или проработать архитектуру. Когда вам предложили доработать архитектуру, вы ответили что у вас сейчас нет ресурса и может не хватить мотивации людей. Вывод думаю очевидный напрашивается.
Прочитав ветку, думаю что нужно монетизировать и работать с клиентами чтобы было чем платить работникам.
После чего можно говорить о бэкенде.
Спрашиваете что делать — удовлетворить клиента или проработать архитектуру. Когда вам предложили доработать архитектуру, вы ответили что у вас сейчас нет ресурса и может не хватить мотивации людей. Вывод думаю очевидный напрашивается.
Прочитав ветку, думаю что нужно монетизировать и работать с клиентами чтобы было чем платить работникам.
После чего можно говорить о бэкенде.
Надо собрать все комментарии разработчиков про бэкенд, систематизировать и сохранить где-нибудь — иначе, когда дело все же дойдет до переписывания бэкенда, никто уже не будет помнить зачем его переписывать-то собрались.
Также имеет смысл заранее продумать архитектуру нового бэкенда, и оценить трудозатраты, результат положить в ту же папочку что и комментарии разработчиков. Такая ситуация, когда уже есть рабочий прототип с набитыми на нем шишками и пока что неограниченное время на проектирование, идеальна для waterfall-разработки, и этим надо воспользоваться.
Непосредственно код нового бэкенда сразу писать не нужно пока старый хорошо работает.
Забавно. Многие проблемы присутствуют и в моей компании, но начальство их вообще не признаёт))
Спасибо большое за великолепную статью!
UFO just landed and posted this here
всегда поражает разница на уровне менталитета:
по-русски это всегда «8 верных способов загубить разработку»
по английски это всегда «Eight Proven Ways to Make Your Project a Success»
по-русски это всегда «8 верных способов загубить разработку»
по английски это всегда «Eight Proven Ways to Make Your Project a Success»
можно и так назвать, хотя в современном варианте это реализовано как minimum viable product (MVP), по сути те же шаги на пути к успешной реализации проекта с промежуточным тестированием и последующим улучшением
однако, думаю, что создатели военных самолетов бы приняли бы идею MVP в контексте невернувшихся машин за величайшее оскорбление, потому что они действительно делали максимум того, что им было доступно
однако, думаю, что создатели военных самолетов бы приняли бы идею MVP в контексте невернувшихся машин за величайшее оскорбление, потому что они действительно делали максимум того, что им было доступно
Уже давно понял, что деньги — не единственная мотивация. Сотрудники ведь не роботы, работая над проектом люди вкладывают плоды творчества. Естественно, им обидно от того, что проект закрывают.
Sign up to leave a comment.
«Пятничный формат»: Как погасить пламя или 8 верных способов загубить разработку