Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 9
если заглянуть в устав любой компании, то окажется, что целью её деятельности является "получение прибыли". про "разработку качественного продукта" там скорее всего ни слова.
поэтому директорат и менеджмент знают, за что они работают, а у разработчиков, выходит, (не)множко сбиты приоритеты.
поэтому директорат и менеджмент знают, за что они работают, а у разработчиков, выходит, (не)множко сбиты приоритеты.
«Разработка качественного продукта» может встретиться, хотя и в другой формулировке. А получение прибыли не вписывается в формулировку миссии организации. Это скорее параллельный процесс, показывающий успешность деятельности фирмы по достижению заявленной миссии. Короче говоря,
© Учебник по менеджменту под редакцией Максимцова М.М. и Комарова М.А.
Миссия организации всегда направлена на внешнюю среду, на удовлетворение потребностей. Не может быть миссией увеличение прибыли организации и другие внутренние цели, даже имеющие стратегический характер.
© Учебник по менеджменту под редакцией Максимцова М.М. и Комарова М.А.
ну разумеется, объявление красивой миссии прямо увеличивает прибыль: больше клиентов захотят придти к.
проще говоря, миссия — это декларации и политика, а устав — это действия и реальность.
да, это наверное плохо и неправильно, но так есть.
ну а на красивую цитату могу ответить другой, не менее красивой:
"Обеспечьте 10 процентов, и капитал согласен на всякое применение, при 20 процентах он становится оживленным, при 50 процентах положительно готов сломать себе голову, при 100 процентах он попирает все человеческие законы, при 300 процентах нет такого преступления, на которое он не рискнул бы, хотя бы под страхом виселицы".
проще говоря, миссия — это декларации и политика, а устав — это действия и реальность.
да, это наверное плохо и неправильно, но так есть.
ну а на красивую цитату могу ответить другой, не менее красивой:
"Обеспечьте 10 процентов, и капитал согласен на всякое применение, при 20 процентах он становится оживленным, при 50 процентах положительно готов сломать себе голову, при 100 процентах он попирает все человеческие законы, при 300 процентах нет такого преступления, на которое он не рискнул бы, хотя бы под страхом виселицы".
Да, только проблема в том, что делая все в этом стиле "а-ля корп", приходится все переделывать по 3-4-5 раз. И тут трудозатраты, и, что более важно - затраты денег ( нахаляву никто ничего не переделывает) - в разы больше, чем сделать все 1 раз, с нормальной архитектурой, расширяемое, и по необходимости дописывать. Зато под переделку - снова можно выбить премии "за выполнение плана". Бред все это про получение прибыли любой ценой. Когда говорят - любой ценой, то цена оказывается в разы выше, чем если бы эта цена и все остальное было оговорено заранее, заложили бы нормальный план, архитектуру, время на рефакторинг и тестирование. А так - вот вам корпорации ваш план, забашляйте за него 3-4-5 раз.
Они же (руководство и всякие "финансисты") почему-то считают, что разработчик, посидев над задачей на неделю меньше, сэкономил компании четверть своего оклада. Но забывают, что потом, переделывая все на 3 недели больше из-за корявой архитектуры, он же потом 3/4 этого оклада потратит. К сожалению это понимают только те, кто выполняет непосредственно работу, а те кто у руля, несутся вперед, и за всякими глупостями они не видят что теряют больше, при таком вот "выполнении планов"
Имхо не стоит делать что-либо, чтобы потом (тут же) переделывать с большими трудозатратами, даже любой ценой. Это порочная практика.
PS Сам к сожалению тоже не могу преодолеть давление "руко-водства", и местами приходится делать "укладываясь в план", или хотя бы пытаться в него укладываться.
Они же (руководство и всякие "финансисты") почему-то считают, что разработчик, посидев над задачей на неделю меньше, сэкономил компании четверть своего оклада. Но забывают, что потом, переделывая все на 3 недели больше из-за корявой архитектуры, он же потом 3/4 этого оклада потратит. К сожалению это понимают только те, кто выполняет непосредственно работу, а те кто у руля, несутся вперед, и за всякими глупостями они не видят что теряют больше, при таком вот "выполнении планов"
Имхо не стоит делать что-либо, чтобы потом (тут же) переделывать с большими трудозатратами, даже любой ценой. Это порочная практика.
PS Сам к сожалению тоже не могу преодолеть давление "руко-водства", и местами приходится делать "укладываясь в план", или хотя бы пытаться в него укладываться.
Например: премия за выполнение плана. Хотя при выполненном плане, могут страдать тонкие моменты реализации, которые проявят себя не сразу.
Тобишь это подразумевает выдачу программы, которая не выдаст ошибки при запуске, выполнит все основные функции, позволит немного что-то по настраивать, где-то выдаст ляп на уровне предупреждения. Но в итоге программа будет вроде работать + премия.
Но... Сколько будет затрачено денег на доведение до ума всего что нужно? Под деньгами имеется ввиду время, затраченное на доработку старого вместо новой разработки?
Всегда ли премия выгодна в таком случае?
С другой стороны, можно попросту утонуть в постоянных разработках "более удобного/быстрого.../надежного и вообще ничего не выпустить.
Не существует идеально качественного софта, се ля ви. Конкуренты не дремлют, пользователи ждать не будут. Дайте программисту время написать какой-либо кусок функционала идеально, и вы увидите что время не лезет ни в какие ворота.
У меня в практике был период когда приложение тестировалось до умопомрачения, вылизывалось просто идеально все. В итоге багфикс перекрыл время разработки, и если реально посмотреть на вылизывание багов, то львиную долю конечный пользователь (или большая часть пользователей) никогда не воспроизведет. Вот тут и работает правило - лучший тестировщик это конечный потребитель. Мило улыбаемся и исправляем ошибки. Так вобщем-то написаны все продукты от MS :)
У меня в практике был период когда приложение тестировалось до умопомрачения, вылизывалось просто идеально все. В итоге багфикс перекрыл время разработки, и если реально посмотреть на вылизывание багов, то львиную долю конечный пользователь (или большая часть пользователей) никогда не воспроизведет. Вот тут и работает правило - лучший тестировщик это конечный потребитель. Мило улыбаемся и исправляем ошибки. Так вобщем-то написаны все продукты от MS :)
Никто не говорит о безумном перфекционизме, но обычно время до плана закладывается на уровне - "программист пишет\тестирует\рефакторит 1 класс за 1.5 дня, для написания программы с 10 классами - ему хватит 2х недель". может не совсем так утрировано, но очень близко.
А потом выясняется что львиную долю разработчик проводит в проектировании архитектуры (или в ее обсуждении с коллегами), взаимодействия классов, создания "расширябельной" структуры приложения. А когда у него 2 недели на все сразу и еще "давят" планом - естественно никто не будет продумывать архитектуру - "некогда топор точить, рубить надо". Вот и получается что при добавлении более-менее простого функционала начинается все заново - все "перепродумать", новая структура взаимодействия.
Улыбаться и исправлять это конечно красиво, но когда времени на исправления уходит много - конкуренты, которые "кладут фиксы" быстрее, за счет продуманной архитектуры - убегают далеко вперед. Есть еще анекдот немного в тему, про молодого и старого быков, которые спускались с горы к коровам - вспомните его, и подумайте, так ли надо бежать за конкурентами...
Про продукты МС - грязная провокация ;) . Вы с какими продуктами МС знакомы на уровне архитектуры? или мнение свое формируете на "читал в инете" ?
А потом выясняется что львиную долю разработчик проводит в проектировании архитектуры (или в ее обсуждении с коллегами), взаимодействия классов, создания "расширябельной" структуры приложения. А когда у него 2 недели на все сразу и еще "давят" планом - естественно никто не будет продумывать архитектуру - "некогда топор точить, рубить надо". Вот и получается что при добавлении более-менее простого функционала начинается все заново - все "перепродумать", новая структура взаимодействия.
Улыбаться и исправлять это конечно красиво, но когда времени на исправления уходит много - конкуренты, которые "кладут фиксы" быстрее, за счет продуманной архитектуры - убегают далеко вперед. Есть еще анекдот немного в тему, про молодого и старого быков, которые спускались с горы к коровам - вспомните его, и подумайте, так ли надо бежать за конкурентами...
Про продукты МС - грязная провокация ;) . Вы с какими продуктами МС знакомы на уровне архитектуры? или мнение свое формируете на "читал в инете" ?
немного о разном говорим :).
Про архитектуру согласен на 100
Про конкурентов не соглашусь, может случится так, что пока старый бык гордо и спокойно спустится с горы, тра%%ть будет уже некого.
Про МС шутка, с долей правды :)
Про архитектуру согласен на 100
Про конкурентов не соглашусь, может случится так, что пока старый бык гордо и спокойно спустится с горы, тра%%ть будет уже некого.
Про МС шутка, с долей правды :)
Хмм, все-таки хоть и "выпустить первым" значит многое в захвате аудитории, но все-же это не основная цель, это просто один из серьезных факторов, но только - один из.
Доля правды там была может быть годах в 90-х, сейчас они основательно переписывают свои подходы, что очень приятно сказывается на продуктах =)
Доля правды там была может быть годах в 90-х, сейчас они основательно переписывают свои подходы, что очень приятно сказывается на продуктах =)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Корпоративная разработка программного обеспечения или бег с препятствиями