Comments 59
Бизнес это не антагонист инженерии, а скорее ее среда. Проблема в том, что к самим бизнес-процессам редко применяется инженерный подход, чаще это что-то типа: «обезьяна видит — обезьяна делает». И академическое образование тут точно не поможет, в виду недостаточной гибкости у всего академического. Методологии, документация и контроль качества могут являться, и часто являются таким-же манки-бизнесом, как и все вокруг. Решение — в правильных людях, которых просто мало, как золота.
Люди-то у нас хорошие. Вопрос в опыте и процессах. Потому и кочуют по компаниям тренеры, которые ставят процессы в компании. Из того их состояния где кому-то что-то ясно как надо делать, в состояние когда каждый знает когда и что ему лично надо делать. Поставленный процесс приносит спокойствие. Есть ответственные за каждый этап разработки. И, главное, все знают кто за что отвечает. Каждый делает свою работу, делает ее хорошо и в срок, и главное не делает лишнего (в отделе маркетинга решили, что этот экран за 3 дня до релиза надо полностью переделать, потому как у прежнего была низкая конверсия).
ПО создается для бизнеса. Это и есть самый главный заказчик.
Скрам конечно пытается убить качество кода ради скорости появления новых фич.
Но никто не мешает обсуждать последствия принятия «простых решений» вместе с бизнесом.
И записывать это в технических долг.
Задокументированный технический долг, он уже не долг — а осознанный риск бизнеса. И за него отвечают бизнесмены.
Скрам конечно пытается убить качество кода ради скорости появления новых фич.
Но никто не мешает обсуждать последствия принятия «простых решений» вместе с бизнесом.
И записывать это в технических долг.
Задокументированный технический долг, он уже не долг — а осознанный риск бизнеса. И за него отвечают бизнесмены.
Если пожеланий более 100, то риск уже не осознаётся.
И решение о улучшении обосновывается на понятном заказчику языке: «Реализация желаемой функциональности при текущем подходе будет стоить X, а смена подхода и реализация той же функциональности будет стоить 70% от X».
И решение о улучшении обосновывается на понятном заказчику языке: «Реализация желаемой функциональности при текущем подходе будет стоить X, а смена подхода и реализация той же функциональности будет стоить 70% от X».
Бизнесу почти всегда нужно «здесь и сейчас», даже если потом придётся всё переписывать. Но психологически, очень неприятно тратить много усилий не на создание чего-то нового, уникального, а на очередное «перекапывание канав». По итогам года, гораздо приятней похвастаться «я сделал вот эти 5 фич», чем оправдываться «я сделал эти 3 фичи, и провёл 2 рефакторинга, потому, что каждая фича требовала переписывания всего». И, безусловно, кто платит, тот и решает. Но не стоит недооценивать силу мотивации/демотивации.
Бизнесу почти всегда нужно «здесь и сейчас», даже если потом придётся всё переписывать.
Это нужно недальновидному бизнесу. Правильный вопрос «Что будет сейчас и что будет через месяц, год?».
Дело, как обычно, в людях.
Если это не осознают отдельные представители менеджмента, не значит, что это не осознает весь бизнес вообще.
Так зачастую никто и не знает что там будет через год :-) Особенно когда продукт ещё не запущен. Может не выгорит и получается зря парились. А может и выгорит и будут средства хоть полностью его переписать.
Насчет «Что будет» я не про пророчества) Я про планирование.
Можно провести аналогию с ребенком.
При зачатии ребенка семья планирует его рождение, делает наметки насчет яслей, детсада, школы, и т.д.
Естественно, все может поменяться — переезды и т.д.
Но тогда просто составляются новые планы, более или менее долгосрочные.
Можно поспорить в стиле «запланировали отдать в музыкальную школу, а ребенок захотел на физмат».
Но это издержки планирования — все равно какое-то долгосрочное планирование есть.
А главное — это сильно отличается от подхода «родили и родили, фиг знает, что будет через год» :)
Правильно выращенный бизнес будет кормить его владельца долгие годы.
С этой точки зрения стоит делать наметки на то, что будет через год.
Ну и подход «Сегодня релизим и продаем! И пофиг, что будет потом» имеет высокие риски в будущем.
Я бы назвал такой подход неприемлемым.
Но у каждого свое видение, т.е. дело в людях)
Можно провести аналогию с ребенком.
При зачатии ребенка семья планирует его рождение, делает наметки насчет яслей, детсада, школы, и т.д.
Естественно, все может поменяться — переезды и т.д.
Но тогда просто составляются новые планы, более или менее долгосрочные.
Можно поспорить в стиле «запланировали отдать в музыкальную школу, а ребенок захотел на физмат».
Но это издержки планирования — все равно какое-то долгосрочное планирование есть.
А главное — это сильно отличается от подхода «родили и родили, фиг знает, что будет через год» :)
Правильно выращенный бизнес будет кормить его владельца долгие годы.
С этой точки зрения стоит делать наметки на то, что будет через год.
Ну и подход «Сегодня релизим и продаем! И пофиг, что будет потом» имеет высокие риски в будущем.
Я бы назвал такой подход неприемлемым.
Но у каждого свое видение, т.е. дело в людях)
Это важно: НЕ «составляются новые планы», а корректируются существующие планы.
Изначальный «план» ДОЛЖЕН составляться на основании четко проработанного и известного Жизненного циклачеловека продукта.
Вероятность изменения содержания и последовательности этапов такого цикла весьма мало.
Наличие в компании знаний о Жизненном цикле продукта позволяет на его основе формировать не только инженерно-технические решения.
Например, появляется возможность производить обоснованные финансовые расчеты для среднесрочной перспективы в зависимости от складывающейся ситуации в настоящий момент. Ценность таких расчетов для планирования деятельности компании сложно переоценить.
И заметьте, это уже не просто планирование, а это оперативный ситуационный прогноз.
Любой бизнесмен будет несомненно доволен, если такой ораКлёвый процесс прогнозирования будущего будет у него на вооружении. И скорее всего, с тем, кто его обеспечит, он поделится самым сокровенным…
Изначальный «план» ДОЛЖЕН составляться на основании четко проработанного и известного Жизненного цикла
Вероятность изменения содержания и последовательности этапов такого цикла весьма мало.
Наличие в компании знаний о Жизненном цикле продукта позволяет на его основе формировать не только инженерно-технические решения.
Например, появляется возможность производить обоснованные финансовые расчеты для среднесрочной перспективы в зависимости от складывающейся ситуации в настоящий момент. Ценность таких расчетов для планирования деятельности компании сложно переоценить.
И заметьте, это уже не просто планирование, а это оперативный ситуационный прогноз.
Любой бизнесмен будет несомненно доволен, если такой ораКлёвый процесс прогнозирования будущего будет у него на вооружении. И скорее всего, с тем, кто его обеспечит, он поделится самым сокровенным…
Цена надежности – это погоня за предельной простотой. Такая цена по карману не каждому богатомуСэр Энтони Хоар, 1980.
«Если компьютерную промышленность вообще можно спасти, только наука о компьютерах способна сделать это». Но может пройти немало времени, пока компьютерная промышленность – в особенности компании, крепко стоящие на ногах – согласятся с этой точкой
зрения. Почти наверняка это потребует больше времени, чем тот ограниченный период, на который они строят свои будущие планы.
Тем временем академический мир – который традиционно строит гораздо более далеко идущие планы – не имеет выбора. Он вынужден совершенствовать лучшие навыки, которые может выработать информатика, и обучать им; чем поддаваться внешнему давлению и распространять сегодняшние заблуждения, лучше прекратить эту деятельность вовсе
Э. Дейкстра, 1985 год.
30 лет почти прошло, а воз и ныне там.
Есть и обратная сторона медали. 8 лет я занимался разработкой: писал код, администрировал сервера и всякое такое, что программисты делают. Сейчас я занимаюсь управлением и думаю, что корень проблемы в том, что большинству программистов вообще по барабану выйдет их продукт в продакшн или нет, им просто нравится писать код, а будет он работать, как его поддерживать, это другая история.
Потому что это не задача программиста — «выводить в продакшн», очевидно. Им пофигу, вы им платите, они пилят. А на высокоморальные ценности, которые нужны компании, а не лично ему — ему наплевать. Для этого есть вы — управленец, и это полнолстью ваша вина.
- В чем именно моя вина?
- Так, я плачу и хочу получить определенный результат, так? Или я могу платить вечно, чтобы пилили? Пойду полью свое дерево, на котором растут деньги
Ваша вина в том, что товар не выведен на рынок. А вы приходите к программистам и кричите — до сих пор не запилили, сколько можно? Уже 6 миллионов потратили, а результата 0. А задачи они себе сами придумывают? А решают тот необходимый для вывода в продакшн функционал тоже они, сроки контроллируют? Нет, вы.
А где я написал, что я кричу «сколько мы потратили и какой результат»? Я немного отличаюсь от сферического менеджера в вакууме тем, что я могу самостоятельно написать 100% кода, который требуется в моей работе. Вот про такое отношение как ваше я и говорил в первом комментарии. Для вас бабло растет на деревьях.
Не однократно слышал эту версию от управленцев.
Но, есть еще и такое мнение:
«Задачи решаются так как они ставятся»
А в большинстве ситуаций, которые я видел, программистам именно так задачи ставятся.
Что-то вроде «Сделайте что нибудь, пофиг что и как, лишь бы завтра страничку в интернете можно было увидеть».
Как только начинаешь объяснять все тонкости, что это не просто «страничка в интернете», что это надо проектировать, разрабатывать, выводить в продакшен, а потом поддерживать и т.д. На тебя управленец смотрит большими глазами и спрашивает «а нафига тратить на это время/деньги, там же просто пару страничек в инете показать? Потом, если что, все сделаем как надо». Но понятное дело, что далеко не пару страничек, а это самое «если что» никогда не ставится в планы и никогда в реале не исполняется.
А потом приходит череда разборок и естественно все теже управленцы, которые не так давно спрашивали «а нафига тратить на это время/деньги», точно так же не моргнув глазом спрашивают «а почему не сделали?».
И потом рассказывают (извините, ничего личного к вам, просто мой жизненный опыт) про то, что программстам все пофиг…
Другми словами, продукт делает команда, в которой все должны иметь ответственность. И если конкретному программеру все пофиг, то тут либо взяли на работу раздолбая и ожидают от него чего-то феерического, либо управление как таковое просто отсутсвует… При чем со вторым вариантом я сталкиваюсь гораздо чаще.
Но, есть еще и такое мнение:
«Задачи решаются так как они ставятся»
А в большинстве ситуаций, которые я видел, программистам именно так задачи ставятся.
Что-то вроде «Сделайте что нибудь, пофиг что и как, лишь бы завтра страничку в интернете можно было увидеть».
Как только начинаешь объяснять все тонкости, что это не просто «страничка в интернете», что это надо проектировать, разрабатывать, выводить в продакшен, а потом поддерживать и т.д. На тебя управленец смотрит большими глазами и спрашивает «а нафига тратить на это время/деньги, там же просто пару страничек в инете показать? Потом, если что, все сделаем как надо». Но понятное дело, что далеко не пару страничек, а это самое «если что» никогда не ставится в планы и никогда в реале не исполняется.
А потом приходит череда разборок и естественно все теже управленцы, которые не так давно спрашивали «а нафига тратить на это время/деньги», точно так же не моргнув глазом спрашивают «а почему не сделали?».
И потом рассказывают (извините, ничего личного к вам, просто мой жизненный опыт) про то, что программстам все пофиг…
Другми словами, продукт делает команда, в которой все должны иметь ответственность. И если конкретному программеру все пофиг, то тут либо взяли на работу раздолбая и ожидают от него чего-то феерического, либо управление как таковое просто отсутсвует… При чем со вторым вариантом я сталкиваюсь гораздо чаще.
По вашей логике, программист может ещё и за финансовой отчётностью компании следить должен? А вдруг у нас денег не хватит заплатить программистам в следующем квартале, чтобы закончить релиз? Сбросить ответственность — это очень хитрый менеджерский ход. И тогда вместо управления мы получаем каждодневные переработки, потому что программист отвечает за вывод кода в «продакшн». Программист должен программировать, тестер проверять, аналитик анализировать, а руководитель руководить. Не заставляйте программиста контролировать сроки релиза, заниматься постановкой, функциональным тестированием, уборкой помещения, мытьём кофе-машины и тогда вы получите качественный результат и в срок.
Да я вроде не заставляю мыть полы и за финансовой составляющей следить не заставляю. Заставляю только за свои слова отвечать и за оценки свои и за то, чтобы делать то, что просили, а не новый фреймворк пробовать. Я вообще только за новые фреймворки, если о них попросили или в свободное от работы время.
Если человек отвлекается, значит он не на своём месте или его что-то не устраивает. Творческий человек из под палки работать не сможет, а программист — это творческая профессия. Это тоже, кстати, вопрос управления.
Ой..., ну все. На что он отвлекается? На Хабр? Вопрос управления? Давайте решим: Закрывать доступ в интернет, телефоны отнимать, чтобы не отвлекались?
Все проще — рынок перегрет, вузы не учат программистов, поэтому даже бездарям на IT-рынке платят сильно выше, чем в среднем по больнице по стране. Нет здоровой конкуренции: вот и все. И так будет происходить, пока не перестроится система образования. Уверяю вас, как только и если в этом секторе появится конкуренция все эти «творческие личности» с треском полетят с работы.
P.S. я продолжаю ревьюировать, а иногда и писать код, администрировать сервера и делать всякое такое почти ежедневно и у меня возникает законный вопрос, почему мне не нужны тепличные условия и я как-то могу писать код в перерывах между скайпом и телефонными звонками, а вот «творческие» — не, не могут.
Все проще — рынок перегрет, вузы не учат программистов, поэтому даже бездарям на IT-рынке платят сильно выше, чем в среднем
P.S. я продолжаю ревьюировать, а иногда и писать код, администрировать сервера и делать всякое такое почти ежедневно и у меня возникает законный вопрос, почему мне не нужны тепличные условия и я как-то могу писать код в перерывах между скайпом и телефонными звонками, а вот «творческие» — не, не могут.
Смею вас разочаровать, конкуренция в этой сфере усилится… только между работодателями. На Западе уже как только не заманивают людей, чуть ли не в пионерские лагери офисы превращают, дают неограниченный отпуск (и даже обязывают брать отпуск! www.paperplanes.de/2014/12/10/from-open-to-minimum-vacation-policy.html). А у нас хотят за зарплату таксиста нанять гуру чтобы сутками над кодом работал.
Я работал «на западе». С бельгийцами и с американцами, если быть точным. Если бы не врожденное мнение западных европейцев, что восточнее Польши живут говорящие обезьяны, они бы все в аутсорс вынесли. Не надо приводить в пример гугл — они монополисты. Я говорю про «специалистов» гораздо более скромной компетенции, чем те, что работаю в гугле.
Ну про какую зарплату таксиста вы говорите? Не нравится рынок в Воронеже — езжайте в Москву или выучите английский и работайте на «заграницу», уверяю вас, если вы «гуру», то за полгода спокойно выйдете на доход от $2500 в месяц, работая на американцев.
Но «за бугром» принято «отвечать за базар» и их я «пилил, но меня отвлекали» не устроит, особенно американцев.
Ну про какую зарплату таксиста вы говорите? Не нравится рынок в Воронеже — езжайте в Москву или выучите английский и работайте на «заграницу», уверяю вас, если вы «гуру», то за полгода спокойно выйдете на доход от $2500 в месяц, работая на американцев.
Но «за бугром» принято «отвечать за базар» и их я «пилил, но меня отвлекали» не устроит, особенно американцев.
brewerof я был и нахожусь с обеих сторон одновременно. Я могу лишь рекомендовать посмотреть с другой стороны. Оттуда видно, что бизнес платит зарплату, что не всегда есть возможность делать долго и качественно. Что иногда выгоднее потом починить или сделать это в процессе, чем медленно довести всё до ума. Потому что, пока вы доводите до ума вам нужна зарплата и одновременно, продукт не выпущен и не приносит денег. Т.е. получается двойной минус. Там, с той стороны, много своих задач и именно эта сторона кормит нас инженеров.
А инженерам стоит быть в курсе стороны бизнеса, потому что это для наших мозгов достаточно просто. Куда проще, чем обычному менеджеру со стороны познать инженерию. А когда вы в курсе, то сможете предлагать и говорить на языке бизнеса.
Ещё один пример. Продукт может иметь малый срок жизни и для него важен баланс качества и цены или скоростные сроки вывода на рынок.
А инженерам стоит быть в курсе стороны бизнеса, потому что это для наших мозгов достаточно просто. Куда проще, чем обычному менеджеру со стороны познать инженерию. А когда вы в курсе, то сможете предлагать и говорить на языке бизнеса.
Ещё один пример. Продукт может иметь малый срок жизни и для него важен баланс качества и цены или скоростные сроки вывода на рынок.
К последним двум абзацам существует специальная цитата.
(Martin Newell, Adobe Fellow)
Ask a mechanical, structural, or electrical engineer how far they would get without a heavy reliance on a firm mathematical foundation, and they will tell you, 'not far.' Yet so-called software engineers often practice their art with little or no idea of the mathematical underpinnings of what they are doing. And then we wonder why software is notorious for being delivered late and full of bugs, while other engineers routinely deliver finished bridges, automobiles, electrical appliances, etc., on time and with only minor defects.
(Martin Newell, Adobe Fellow)
В том-то и дело, что 99% фирм не нужен софт, который будет работать десятилетия, потому, что он устареет уже через год, зато им нужна быстрая отдача и минимум вложений.
Вот и получается, что проектирование моста — долгий и кропотливый процесс, который может занимать даже больше времени, чем его постройка. А об архитектуре приложения задумываются лишь после того как оно уже отбило вложения и «чё-то как-то багов много» и «надо бы ускориться». И тогда нанимают «сеньёров», рассчитывая, что они, как профессионалы, доведут до ума малой кровью. Но правда в том, что никакой малой кровью деревянный мост на подпорках не превратить в железный многотоннажный. А для превращения дерева в металл даже алхимикам нужно много крови.
Уважаемый krasko, в последних двух абзацах я не написал ничего, что относится к этой замечательной цитате.
Музыкант не должен играть без нот, а инженер работать
Если есть знакомые/друзья которые учились например в немецких технических ВУЗах, поитересуйтесь как, когда и в какой форме там дается математика.
Музыкант не должен играть без нот, а инженер работать
«with little or no idea of the mathematical underpinnings of what they are doing»Но! Математика для инженерии и инженерия для математики — это две большие разницы. Я видел senior'ов с «solid mathematical background», но не знающих, что код метода не должен быть длиной 342 строки.
Если есть знакомые/друзья которые учились например в немецких технических ВУЗах, поитересуйтесь как, когда и в какой форме там дается математика.
Про то, что код метода не должен быть длиной 342 строки, инженеру сообщат на первой работе, пока он будет джуниором. Там же он познакомится ещё с тысячей других технических деталей, с которыми знакомиться там и место.
Что там у немцев знаю плохо, зато знаю, что наши инженеры востребованы по всему миру, причём часто потому, что с математикой у них более-менее, в отличие от многих их западных коллег. Но инженерия уходит вперёд, появляются новые концепции, многие из которых имеют сильные математические основания, и которые нужно применять с умом и понимать. Математика также развивается, а вот вузы наши отстают — это повод переработать существующие курсы и выкинуть кучу хлама (взятие 100 производных и интегралов руками на 1 курсе), добавить больше содержательной математики, полезной программисту (дискретная математика, алгоритмы, теория типов). Это проблема вузов, а не математики, что в них учат не тому.
Курсы про процесс разработки в вузах должны быть лишь кратким обзором того, с чем придётся столкнуться инженеру, а не ядром всего обучения, по двум причинам. Во-первых, потому что есть куча куда более важных концепций, которым можно научить в вузе. Во-вторых, потому что учить про то, как строить действительно большие проекты вместе с большой командой инженеров, можно только на примере больших проектов и большой команды инженеров. В таком проекте надо долго разбираться (ещё и в каждом по-своему; долго, но не концептуально трудно!), и это тема не короткого и базового университетского образования, а вполне боевая задача.
В этом смысле очень разумная идея — делать школы программирования при фирмах, что часто и делается. Там дают более специальные знания. В них учат тому, что у них получается лучше, в вузах — тому, что у них. Также, разумный будущий инженер будет сам читать книжки про процесс разработки. Работает это в сто раз лучше универских курсов. С математикой, кстати, такой трюк не проходит; ну либо проходит у очень малого числа людей.
Что такое математика для инженеров я понял, в вот что такое инженерия для математики я вообще плохо себе представляю (написание систем компьютерной алгебры?).
Что там у немцев знаю плохо, зато знаю, что наши инженеры востребованы по всему миру, причём часто потому, что с математикой у них более-менее, в отличие от многих их западных коллег. Но инженерия уходит вперёд, появляются новые концепции, многие из которых имеют сильные математические основания, и которые нужно применять с умом и понимать. Математика также развивается, а вот вузы наши отстают — это повод переработать существующие курсы и выкинуть кучу хлама (взятие 100 производных и интегралов руками на 1 курсе), добавить больше содержательной математики, полезной программисту (дискретная математика, алгоритмы, теория типов). Это проблема вузов, а не математики, что в них учат не тому.
Курсы про процесс разработки в вузах должны быть лишь кратким обзором того, с чем придётся столкнуться инженеру, а не ядром всего обучения, по двум причинам. Во-первых, потому что есть куча куда более важных концепций, которым можно научить в вузе. Во-вторых, потому что учить про то, как строить действительно большие проекты вместе с большой командой инженеров, можно только на примере больших проектов и большой команды инженеров. В таком проекте надо долго разбираться (ещё и в каждом по-своему; долго, но не концептуально трудно!), и это тема не короткого и базового университетского образования, а вполне боевая задача.
В этом смысле очень разумная идея — делать школы программирования при фирмах, что часто и делается. Там дают более специальные знания. В них учат тому, что у них получается лучше, в вузах — тому, что у них. Также, разумный будущий инженер будет сам читать книжки про процесс разработки. Работает это в сто раз лучше универских курсов. С математикой, кстати, такой трюк не проходит; ну либо проходит у очень малого числа людей.
Что такое математика для инженеров я понял, в вот что такое инженерия для математики я вообще плохо себе представляю (написание систем компьютерной алгебры?).
Код метода в 342 строки — это очевидное нарушение одного из базовых принципов проектирования ПО, single responsibility principle. И это не «техническая деталь», с которой «знакомиться там и место», а то, что превратит код проекта в «большой ком грязи», ну или «спагетти-код», кому как нравится.
Базовые знания о проектировании ПО должны разумеется закладываться в ВУЗе, на профильных дисциплинах — ООП, технологии разработки ПО, контруирование ПО и тд
Базовые знания о проектировании ПО должны разумеется закладываться в ВУЗе, на профильных дисциплинах — ООП, технологии разработки ПО, контруирование ПО и тд
Когда джуниор первый раз напишет спагетти-код, а ещё лучше, когда он попытается разобраться в чужом спагетти-коде и поймёт, что так делать нельзя, тогда и придёт понимание этого single responsibility principle. Для этого не обязательно учиться в вузе вообще. Это вещи, с одной стороны, лежащие на поверхности, с другой — приходящие только с опытом. Для лучшего понимания таких вещей, для анализа примеров, есть книги от признанных авторитетов разработки, которые разработчик должен прочитать в дополнение к вузовской программе по собственному желанию. В вузе можно дать пару таких курсов в семестре перед дипломом (чтобы студенты просто знали, куда глядеть; достаточно, возможно, просто нескольких лекций), но базировать всё обучение на них ни в коем случае нельзя.
В примере с сеньором, не знающим указанного принципа, похоже, этому сеньору уже ничто не поможет (как не помог бы и курс по разработке ПО), а весь его сильный математический бэкграунд — миф, которым можно обманывать тех, кто сам в этой математике ничего не понимает.
В примере с сеньором, не знающим указанного принципа, похоже, этому сеньору уже ничто не поможет (как не помог бы и курс по разработке ПО), а весь его сильный математический бэкграунд — миф, которым можно обманывать тех, кто сам в этой математике ничего не понимает.
Для этого не обязательно учиться в вузе вообще.?
-Участвовать в проведении научных исследований (экспериментов, наблюдений и количественных измерений) программных продуктов, проектов, процессов, методов и инструментов программной инженерии
-Заниматься построением моделей программных проектов и программных продуктов с использованием инструментальных средств компьютерного моделирования
-Составлять описания проводимых исследований, готовить данные для составления обзоров и отчетов
-Заниматься сбором и анализом требований заказчика к программному продукту
-Помогать заказчику в оценке и выборе вариантов программного обеспечения
-Участвовать в составлении коммерческого предложения заказчику, готовить презентации и согласовывать пакет договорных документов
-Проектировать компоненты программного продукта в объеме, необходимом для их конструирования в рамках поставленного задания
-Создавать компоненты программного обеспечения (кодирование, отладка, модульное и интеграционное тестирование)
-Выполнять измерения и рефакторинг кода в соответствии с планом
-Заниматься разработкой тестового окружения и созданием тестовых сценариев
-Разрабатывать и оформлять эскизную, техническую и рабочую проектную документацию
-Осваивать и применять средства автоматизированного проектирования, разработки, тестирования и сопровождения программного обеспечения
-Осваивать и применять методы и инструментальные средства управления инженерной деятельностью и процессами жизненного цикла программного обеспечения
-Осуществлять контроль, оценку и обеспечение качества программной продукции
-Обеспечивать соответствие разрабатываемого программного обеспечения и технической документации российским и международным стандартам, техническим условиям, нормативным документам и стандартам предприятия
-Участвовать в процессах разработки программного обеспечения
-Участвовать в создании технической документации по результатам выполнения работ
-Проводить обучение и аттестацию пользователей программных систем
-Участвовать в разработке методик обучения технического персонала и пособий по применению программных систем
-Участвовать в составлении технической документации (графиков работ, инструкций, планов, смет, заявок на материалы, оборудование, программное обеспечение)
-Планировать и координировать работу по настройке и сопровождению программного продукта
-Организовывать работу малых коллективов исполнителей программного проекта
-Вводить в эксплуатацию программное обеспечение (осуществлять инсталляцию, настраивать параметры, адаптировать, администрировать)
-Осуществлять профилактическое и корректирующее сопровождение программного продукта в процессе эксплуатации
-Обучать и консультировать пользователей по работе с программной системой
Чем быдлокодер, получившийся в результате неких «курсов», отличается от инженера по разработке ПО, можно попытаться понять например тут.
Ну в общем-то как раз cейсчас пишу статью «freelance — you're doing it wrong», в рамках которой описываю основные организационные и управленческие проблемы с которыми мне приходилось сталкиваться.
Если кратко, то это
Я могу продолжать, это неполный список.
Опять же примитивное гнилое постсоветское общество с протёртыми книжными проблемами передача которых с поколения в поколение ещё и поддерживается родственниками и окружением. Та-да…
Если кратко, то это
- Дилетанство и предрассудки — заказчики/руководство не способны учится даже на своих собственных ошибках
- Ригидность — не способны адаптироваться к новым условиям
- Желание сэкономить, часто на организации труда — напрочь убивают поддержку
- Неспособность адекватно оценивать риски. Все риски делегируют посредникам — убивают масштабирование.
- Личные психологические расстройства и компенсаторные процессы:
- Я хочу быть самым умным и/или самым главным...
- Я хочу подчинятся...
… а не разрабатывать качественные, надёжные и конкурентоспособные продукты.
Конечно они могут встретить друг друга, но одному нужно страдать, а другому нужно быстрое удовлетворение его желаний, желательно даром.
Я могу продолжать, это неполный список.
Опять же примитивное гнилое постсоветское общество с протёртыми книжными проблемами передача которых с поколения в поколение ещё и поддерживается родственниками и окружением. Та-да…
UFO just landed and posted this here
Красота кода — это не главный критерий, код не картина и не женщина, главный критерий — эффективность. Красота это производная эффективности скорее…
Базовые цели у заказчика и исполнителя на самом деле совпадают — решить задачи с минимальными потерями времени, денег и нервных клеток.
Есть набор практик, которые были созданны отнюдь не глупыми людьми, и совсем не теоретиками. Эти практики как раз и направлены на обход всевозможных граблей и, в конечном итоге, на экономию времени, денег и нервных клеток.
Только заказчик/менеджмент проекта зачастую воспринимает эти практики, как какие-то глупые, ненужные и совершенно излишние вещи.
Итог — скупой платит дважды, или как говорят автомобилисты «кроилово ведет к попадалову». Поэтому я и говорю про образование — человек владеющий этими методологиями, понимающий их важность, решать бизнес-задачи будет гораздо эффективней.
Базовые цели у заказчика и исполнителя на самом деле совпадают — решить задачи с минимальными потерями времени, денег и нервных клеток.
Есть набор практик, которые были созданны отнюдь не глупыми людьми, и совсем не теоретиками. Эти практики как раз и направлены на обход всевозможных граблей и, в конечном итоге, на экономию времени, денег и нервных клеток.
Только заказчик/менеджмент проекта зачастую воспринимает эти практики, как какие-то глупые, ненужные и совершенно излишние вещи.
Итог — скупой платит дважды, или как говорят автомобилисты «кроилово ведет к попадалову». Поэтому я и говорю про образование — человек владеющий этими методологиями, понимающий их важность, решать бизнес-задачи будет гораздо эффективней.
UFO just landed and posted this here
>если у Вас есть конкретная мысль как правильно делать, было бы интересно её услышать…
Из своего опыта могу сказать, что идея одна и она отлично работает — «всегда надо смотреть по ситуации».
Для меня все эти методики синонимы здравого смысла.
Если очень коротко, то опыт кока-колы отлично подойдет если вы строите полный аналог бизнеса кока колы, опыт ай-би-эм если вы строите аналогичный бизнес и т.д… Но даже в этом случае нет гарантий, что эти методики подойдут людям которые у вас в команде. В общем отношусь к опыту других компаний по принципу «Сказка ложь, да в ней намёк...».
Просто видел не один раз, когда брали опыт огромной компании и пытались «натянуть» на маленькую компанию. Я это обычно называю «выключить мозг». Тут дело даже не в самом размере, а в том что организация работы 5 человек и 100 человек сильно отличается.
К тому же менталитет людей сильно отличается. Да и цели и задачи могут отличаться.
Поэтому всегда надо смотерть по ситуации. При чем большую часть внимания надо уделить людям, ибо они в конечном итоге решают, а не методики.
Как пример, участвовал в одном проекте, где как такового планирования/проектирования не было вообще. Тогда еще не было этого хайпа во круг аджайла и прочих скрамов. Но команда была на столько удачной, что они самоорганизовывались без проблем. Короткая летучка, определяли следующий шаг и впреред.
Из своего опыта могу сказать, что идея одна и она отлично работает — «всегда надо смотреть по ситуации».
Для меня все эти методики синонимы здравого смысла.
Если очень коротко, то опыт кока-колы отлично подойдет если вы строите полный аналог бизнеса кока колы, опыт ай-би-эм если вы строите аналогичный бизнес и т.д… Но даже в этом случае нет гарантий, что эти методики подойдут людям которые у вас в команде. В общем отношусь к опыту других компаний по принципу «Сказка ложь, да в ней намёк...».
Просто видел не один раз, когда брали опыт огромной компании и пытались «натянуть» на маленькую компанию. Я это обычно называю «выключить мозг». Тут дело даже не в самом размере, а в том что организация работы 5 человек и 100 человек сильно отличается.
К тому же менталитет людей сильно отличается. Да и цели и задачи могут отличаться.
Поэтому всегда надо смотерть по ситуации. При чем большую часть внимания надо уделить людям, ибо они в конечном итоге решают, а не методики.
Как пример, участвовал в одном проекте, где как такового планирования/проектирования не было вообще. Тогда еще не было этого хайпа во круг аджайла и прочих скрамов. Но команда была на столько удачной, что они самоорганизовывались без проблем. Короткая летучка, определяли следующий шаг и впреред.
UFO just landed and posted this here
У меня нет конкретных мыслей как все правильно делать, если нет конкретной вводной.
Налаживание процесса даже в небольших командах — задача довольно трудоемкая я таящая в себе множество подводных камней.
В Вашей ситуации возможно есть смысл «схантить» менеджера из состоявшейся серьезной софтверной фирмы, который имеет реальный опыт оценки и распределения ресурсов, организации и налаживания взаимодействия группы (нескольких групп) разработчиков, контроля качества продукта, развертывания (поставки), и, самое главное, реальные проекты, «ушедшие» в продакшн.
Идеальный вариант, проектов схожей направленности и схожих масштабов.
Возможно ошибка, что Вы сделали ставку на людей из академической среды, плюс не имевших опыта конкретно в этом виде деятельности. Дьявол в мелочах, как известно H2O и H2SO4 отличаются только одним элементом. Самые лучшие практики, использованные не по назначению, разумеется могут дать противоположенный эффект, тут нет ничего удивительного.
Налаживание процесса даже в небольших командах — задача довольно трудоемкая я таящая в себе множество подводных камней.
В Вашей ситуации возможно есть смысл «схантить» менеджера из состоявшейся серьезной софтверной фирмы, который имеет реальный опыт оценки и распределения ресурсов, организации и налаживания взаимодействия группы (нескольких групп) разработчиков, контроля качества продукта, развертывания (поставки), и, самое главное, реальные проекты, «ушедшие» в продакшн.
Идеальный вариант, проектов схожей направленности и схожих масштабов.
Возможно ошибка, что Вы сделали ставку на людей из академической среды, плюс не имевших опыта конкретно в этом виде деятельности. Дьявол в мелочах, как известно H2O и H2SO4 отличаются только одним элементом. Самые лучшие практики, использованные не по назначению, разумеется могут дать противоположенный эффект, тут нет ничего удивительного.
Образование нужно скорее не в сфере программной инженерии, а в сфере менеджмента. Менеджеры (на стороне бизнеса) должны понимать чем хороший (эффективный) заказчик ИТ-решений отличается от чудака который может только истерики устраивать и корчить из себя требовательного начальника.
Насчет того что «Инженерная деятельность — это служанка бизнеса». Действительно, наверняка многие руководители рассуждают в таком духе: вот я такой умный и красивый, разбогател на торговле шпингалетами, у меня есть секретарша, водитель, штат грузчиков, менеджеры по продажам — я их всех успешно дрессирую. Давайте я еще возьму себе программистов и тоже буду их дрессировать.
Тут, на мой взгляд, вопрос в том что команда разработчиков — это для заказчика в большей степени партнеры по бизнесу. Их нельзя дрессировать. Их надо аккуратно выбирать (уметь отличать хороших от плохих — что само по себе крайне сложно) и выстраивать партнерские отношения, считаться с мнениями и интересами. А культура кооперации и договороспособности в среднем по стране, мягко говоря, не на очень высоком уровне. Это не только проблема ИТ.
Тут, на мой взгляд, вопрос в том что команда разработчиков — это для заказчика в большей степени партнеры по бизнесу. Их нельзя дрессировать. Их надо аккуратно выбирать (уметь отличать хороших от плохих — что само по себе крайне сложно) и выстраивать партнерские отношения, считаться с мнениями и интересами. А культура кооперации и договороспособности в среднем по стране, мягко говоря, не на очень высоком уровне. Это не только проблема ИТ.
самое обидное, что это:
Бизнесс постоянно покупает глючное страшное убогоеговно ПО, просто потому, что его уже несколько десятилетий пилит фирма с репутацией.
И даже если после следующего обновления для использования их ПО придётся вставлять анальный зонд — это никак не изменит репутацию фирмы-разработчика и не повлияет на продажи.
Пару примеров:
ПО для управления проектами стоит десятки тысяч евро. Когда я, как сисадмин попросил их прислать msi что бы установить на ПК пользователей централизовано и автоматически. Мне прислали ответ: извините, но человек который умел делать msi уволился.
Или официальный софт для СКД при любом действии с пользователем выдает TB:user error ничего не записывая в логи. Связался с тех поддержкой… ответ: Не обращайте внимания — это нормально. Никаких патчей разумеется не выслали. Этой версии уже несколько месяцев, и когда будет следующий релиз неизвестно.
Результат – баги, выпорхнувшие в релиз из-за такого отношения к QA, наносят такой репутационный и финансовый ущерб компании, по сравнению с которыми затраты на постановку реально эффективного процесса работы с качеством продукта покажутся мизерными.не так.
Бизнесс постоянно покупает глючное страшное убогое
И даже если после следующего обновления для использования их ПО придётся вставлять анальный зонд — это никак не изменит репутацию фирмы-разработчика и не повлияет на продажи.
Пару примеров:
ПО для управления проектами стоит десятки тысяч евро. Когда я, как сисадмин попросил их прислать msi что бы установить на ПК пользователей централизовано и автоматически. Мне прислали ответ: извините, но человек который умел делать msi уволился.
Или официальный софт для СКД при любом действии с пользователем выдает TB:user error ничего не записывая в логи. Связался с тех поддержкой… ответ: Не обращайте внимания — это нормально. Никаких патчей разумеется не выслали. Этой версии уже несколько месяцев, и когда будет следующий релиз неизвестно.
Мне кажется, что проблема тут в отсутствии взаимопонимания, даже скорее взаимопроникновения знаний. Менеджер, работающий в контакте с командой программистов, обязательно должен обладать неким базовым набором знаний в программной инженерии, иначе он не сможет понять причины возникновения тех рисков, о которых ему будут говорить разработчики. А значит, он от них просто отмахнется. С другой стороны, разработчики должны понимать, для каких целей они делают ПО, кто и как им будет пользоваться, и в какую сторону оно предположительно будет развиваться (если вообще будет).
В конечном итоге, менеджер и команда разработчиков должны ДОГОВАРИВАТЬСЯ друг с другом, и не ударяться в крайности, а принимать компромиссные решения, которые позволят не только снять сливки сейчас, но и продолжить это делать в течении длительного времени с минимальными затратами.
В конечном итоге, менеджер и команда разработчиков должны ДОГОВАРИВАТЬСЯ друг с другом, и не ударяться в крайности, а принимать компромиссные решения, которые позволят не только снять сливки сейчас, но и продолжить это делать в течении длительного времени с минимальными затратами.
Душевно. Относится не только к России; у нас в Заливной Области та же фигня. Так что валить на особенности русского образования, бизнеса, менталитета вряд ли имеет смысл. И китайцы такие же, и индийцы такие же, и местные такие же, и европейцы едут такие же; различается только внешний стиль.
Много причин. Цельной науки на тему, как выглядит вообще компьютинг, пока что не существует в природе; и то, что существует, по большей части неизвестно инженерам; так что все равно же делают что могут и как могут.
С другой стороны, у менеджеров в бизнесе горизонт — полгода, а то и пара недель. Ну и даже если нет, найти причину прищучить инженеров («это ваши ошибки» (которые вы допустили, слушаясь меня)), чтобы слушались лучше.
Много причин. Цельной науки на тему, как выглядит вообще компьютинг, пока что не существует в природе; и то, что существует, по большей части неизвестно инженерам; так что все равно же делают что могут и как могут.
С другой стороны, у менеджеров в бизнесе горизонт — полгода, а то и пара недель. Ну и даже если нет, найти причину прищучить инженеров («это ваши ошибки» (которые вы допустили, слушаясь меня)), чтобы слушались лучше.
А в чём собственно проблема? Заказчик/бизнес дурак? — Ну и пусть страдает и умирает. Люди платят за плохой софт? — Это их выбор. Бедному инженеру программисту не нравится делать плохой софт? — Да делай хороший и продавай, не можешь — делай то что тебе говорят и не ной. И да — это бизнес, а не научная деятельность.
Я думаю стоит изменить отношение к своей работе, к работе приложений, к людям. Вы просто делаете то что от вас требуют и получаете за это деньги, всё. Всё остальное не ваше дело пока вам платят. В свободное от работы время можете писать и проектировать всё что вам угодно. Программист вообще всегда в шоколаде, это у менеджеров и руководителей голова должна болеть.
Я думаю стоит изменить отношение к своей работе, к работе приложений, к людям. Вы просто делаете то что от вас требуют и получаете за это деньги, всё. Всё остальное не ваше дело пока вам платят. В свободное от работы время можете писать и проектировать всё что вам угодно. Программист вообще всегда в шоколаде, это у менеджеров и руководителей голова должна болеть.
Мой коллега-программист, когда менеджер стал учить его жизни, так, вполголоса сказал — ну, типа, я менеджеров уже с десяток тут повидал, а я здесь двадцать лет код пишу.
Да… ну прямо бальзам на душу.
Понимаю, разделяю, почти во всем с Вами (с автором статьи) согласен.
Но вот тут:
есть неопределенность, по крайней мере у меня.
Неоднократно «приходил» с этими целями (какое-то время работал в университете, потом просто читал тематические лекции по приглашению коллег).
Но аудитория не всегда готова к тому, о чем я пытаюсь рассказать. Ты им про архитектурные решения, а они ничего больше 30 строк (кода) в своей жизни не писали. Тут нужна систематическая работа. Что бы все учебные курсы были правильно логически выстроены, и читались со 100%-ной отдачей опытными людьми. Как бы, сферический конь в вакууме получается.
Еще один момент. Ловлю себя на мысли, что вот я рассказываю студентам о том как надо программировать (по моему мнению), прихожу на работу, а там все как Вы описываете, и бизнес, и сроки. Да… еще есть коллеги-программисты, для которых тоже, иногда, не хватает аргументов объяснить, что «так делать в репозиторий не хорошо» (если по-мягче выразиться). Ведь неопределенные фразы: «лучше», «более гибко», «легче поддерживать» вызывают такие же блестящие ответы: «но так тоже работает», «а зачем нам гибкость, надо быстро сделать», «а мы поддерживать не собираемся» соответственно. Так зачем я студентам голову то морочу? Может пусть программируют как умеют?
Но силы бороться пока есть :)
Понимаю, разделяю, почти во всем с Вами (с автором статьи) согласен.
Но вот тут:
надеюсь, больше людей будут приходить из реальной разработки в качестве преподавателей в ВУЗы
есть неопределенность, по крайней мере у меня.
Неоднократно «приходил» с этими целями (какое-то время работал в университете, потом просто читал тематические лекции по приглашению коллег).
Но аудитория не всегда готова к тому, о чем я пытаюсь рассказать. Ты им про архитектурные решения, а они ничего больше 30 строк (кода) в своей жизни не писали. Тут нужна систематическая работа. Что бы все учебные курсы были правильно логически выстроены, и читались со 100%-ной отдачей опытными людьми. Как бы, сферический конь в вакууме получается.
Еще один момент. Ловлю себя на мысли, что вот я рассказываю студентам о том как надо программировать (по моему мнению), прихожу на работу, а там все как Вы описываете, и бизнес, и сроки. Да… еще есть коллеги-программисты, для которых тоже, иногда, не хватает аргументов объяснить, что «так делать в репозиторий не хорошо» (если по-мягче выразиться). Ведь неопределенные фразы: «лучше», «более гибко», «легче поддерживать» вызывают такие же блестящие ответы: «но так тоже работает», «а зачем нам гибкость, надо быстро сделать», «а мы поддерживать не собираемся» соответственно. Так зачем я студентам голову то морочу? Может пусть программируют как умеют?
Но силы бороться пока есть :)
По теме статьи можно сказать одной фразой:
Культура бизнеса (читай «делания денег») определяет культуру производства,
и, следовательно, существенно влияет на то, что производится для нашего потребления.
… ну, и чтобы печально замкнуть цикл процитирую: "мы есть то, что потребляем".
Культура бизнеса (читай «делания денег») определяет культуру производства,
и, следовательно, существенно влияет на то, что производится для нашего потребления.
… ну, и чтобы печально замкнуть цикл процитирую: "мы есть то, что потребляем".
Sign up to leave a comment.
Бизнес vs программная инженерия