_>И первая же проблема — как убедить его в том, что процесс программирования в настоящее время некоторым образом отличается от процесса, который был 30 лет назад и заключался в кодировании прямоугольников-ромбиков-переходов?
Я тебе страшную тайну открою: принципиально ничего не изменилось, все то же кодирование прямоугольников-ромбиков-переходов, разница только в синтаксисе языков, правилах расстановки стрелочек между прямоугольниками-ромбиками и навороченных IDE для кодирования прямоугольников-ромбиков.
_>В итоге, вместо того, чтобы полноценно работать, люди днями и неделями занимаются исследовательско-литературной работой на тему "Придумай обоснование".
Так лучше этими днями и неделями вместо подобной фигни втихаря заниматься рефакторингом (не обязательно глобальным, хотя бы мелким рефакторингом). По времени то же самое, а пользы на будущее больше.
_>Что можно придумать? Как убедительно убедить в том, что программирование — это сложно, что качественный подход — необходим, что программа сейчас — это не просто последовательность строк на фортране?
Пытаться убедить в том, что кошерные подходы к программированию лучше некошерных — дохлый номер. Если надо человека в чем-то убедить, то надо плясать от рисков: аргументированно рассказать, какой пипец наступит в результате неправильного подхода (конечно, если в твоей задаче это на самом деле так. А может, там и правда качество кода пофиг.)
Возникла следующая проблема.
Работаю в бывшем гос предприятии, теперь — ЧАО, сфера деятельности — автоматизация тех процесса (АЭС, ЖД — преимущественно АЭС, программно-технические комплексы управления различными узлами станций, в том числе и критически важными).
Так сложилось исторически, что высшее руководство предприятия — выходцы из старых времен (инженеры, электроники). То есть, о современном программировании понятия не имеют практически никакого.
Вследствие истории происхождения предприятия, схем отмывания денег, получения договоров и т.п., качество производимой продукции стоит не в приоритете — стандартный процесс формального выполнения требований в нереальные сроки. В силу того, что предприятие территориально находится в неблагоприятном районе с точки зрения выбора работы (для программистов альтернативы нету в принципе — кроме как мигрировать в другие города или фрилансить) — есть много хороших спецов, которые кое-как тянут на себе проекты.
Поражает тот факт, что у всего многообразия различных комиссий (МАГАТЭ и прочих) не возникают вопросы по поводу отсутствующего у нас отдела тестирования. Хотя, вследствие вышеизложенного, уже не возникают.
Но речь не об этом, а вот о чем: в верху иерархии распределения работ/фондов оплаты труда стоит зам директора, инженер-электроник, уже несколько лет как на пенсии. Я с недавнего времени получил в подчинение пару сотрудников, и в круг моих задач добавилось выбивание работы и денег у этого человека. И первая же проблема — как убедить его в том, что процесс программирования в настоящее время некоторым образом отличается от процесса, который был 30 лет назад и заключался в кодировании прямоугольников-ромбиков-переходов?
Вот конкретная работа: есть у нас несколько проектов, некоторые — крупные, написанные уже довольно давно (C++, MFC, wxWidgets, Qt). Все — с русскоязычным интерфейсом. Никакого юникода (то есть, нагромождение строковых типов — char*, CString и т.п.). Необходимо адаптировать исходники к локализации на другие языки. Кода много — в перспективе светит адова работенка. По мнению замдиректора — это "обезьянья работа", заключающаяся в тупой замене содержимого кавычек новым текстом. О разных типах, о универсальной подсистеме локализации (при добавлении нового языка — будем копировать проект и еще раз менять содержимое кавычек) он слышать не желает. Тычет свой фортран, на котором он текст в кавычках очень просто когда-то выводил и там нет ничего сложного. Это просто пример, аналогичная ситуация возникает постоянно. Никакие, повторяю, никакие доводы не работают, даже если мы ему покажем наши исходники — его логика элементарна (текст -> кавычки — замена всего что в кавычках -> если у нас не так, то мы дебилы).
Возможно, если лизать ему пятки, то по деньгам можно будет проще договориться — но это не путь достойных.
В итоге, вместо того, чтобы полноценно работать, люди днями и неделями занимаются исследовательско-литературной работой на тему "Придумай обоснование".
Знаю, что нужно валить отсюда как можно дальше и быстрее — но в силу некоторых причин пока этого сделать не могу, да и это принципиальный для меня вопрос, попробовать просветлить этого человека, хотя бы чтобы тем, кто после меня останется, было легче.
Что можно придумать? Как убедительно убедить в том, что программирование — это сложно, что качественный подход — необходим, что программа сейчас — это не просто последовательность строк на фортране? Личные доводы не работают, или же я еще не придумал правильные доводы. Возможно, есть какие-то авторитетные статьи такого плана? Литература?
Здравствуйте, lexer_lx, Вы писали:
_>Вот конкретная работа: есть у нас несколько проектов, некоторые — крупные, написанные уже довольно давно (C++, MFC, wxWidgets, Qt). Все — с русскоязычным интерфейсом. Никакого юникода (то есть, нагромождение строковых типов — char*, CString и т.п.). Необходимо адаптировать исходники к локализации на другие языки. Кода много — в перспективе светит адова работенка. По мнению замдиректора — это "обезьянья работа", заключающаяся в тупой замене содержимого кавычек новым текстом. О разных типах, о универсальной подсистеме локализации (при добавлении нового языка — будем копировать проект и еще раз менять содержимое кавычек) он слышать не желает. Тычет свой фортран, на котором он текст в кавычках очень просто когда-то выводил и там нет ничего сложного. Это просто пример, аналогичная ситуация возникает постоянно. Никакие, повторяю, никакие доводы не работают, даже если мы ему покажем наши исходники — его логика элементарна (текст -> кавычки — замена всего что в кавычках -> если у нас не так, то мы дебилы).
Лично я, в такой ситуации, исхожу из предпосылки, что все правы. Тогда, в Вашем случае, выносим все строки в один header локализации, в коде остаются константы, при сборке подсовываем нужный header локализации. Так и переводчику работать легче будет, и быстродействие не пострадает, вполне здоровый подход для систем реального времени (намек ведь на них?). И, что немаловажно, все довольны.
Здравствуйте, lexer_lx, Вы писали:
_>В силу того, что предприятие территориально находится в неблагоприятном районе с точки зрения выбора работы (для программистов альтернативы нету в принципе — кроме как мигрировать в другие города или фрилансить) — есть много хороших спецов, которые кое-как тянут на себе проекты.
первый нюанс насчет хороших спецов — я тоже, пока не начал работать в столице думал, что очень крут , в провинции не только с деньгами проблема, там вообще с it проблема, хочешь расти как специалист — валить в крупный город, без вариантов (потом можно и на удаленку)
_>Что можно придумать? Как убедительно убедить в том, что программирование — это сложно, что качественный подход — необходим, что программа сейчас — это не просто последовательность строк на фортране? Личные доводы не работают, или же я еще не придумал правильные доводы. Возможно, есть какие-то авторитетные статьи такого плана? Литература?
ответ простой — никак, проблема в том, что на твоем предприятии (я сталкивался с такими, очень узнаваемо) качественный код просто никому не нужен — как-то работает и хрен с ним
Здравствуйте, lexer_lx, Вы писали:
_>Так сложилось исторически, что высшее руководство предприятия — выходцы из старых времен (инженеры, электроники). То есть, о современном программировании понятия не имеют практически никакого.
Никак. Не мечи бисер, подумай о своем профессиональном развитии в другом месте.
Здравствуйте, lexer_lx, Вы писали:
_>Проблемы есть — низкое качество продуктов их, допустим, не волнует, а вот срыв сроков — это запросто. Можно показать, что срыв сроков есть следствие низкого качества продуктов и малых вложений в проработку продукта (архитектуры) на начальной стадии.
Заходи с тематики решения тех проблем, которые реально парят начальство, тогда имеешь шанс быть услышанным.
Здравствуйте, lexer_lx, Вы писали:
_>Пожалуй это действительно бесперспективное занятие. Несколько шаблонов убеждения есть, буду стучаться с ними иногда, вдруг там кто-нибудь да откроет. _>А лишнее время лучше пустить на рефакторинг.
если еще молодой, то беги оттуда пока не поздно, оглянуться не успеешь — жена, дети, дача... и хрен потом куда денешься
Здравствуйте, lexer_lx, Вы писали:
_>Что можно придумать? Как убедительно убедить в том, что программирование — это сложно, что качественный подход — необходим, что программа сейчас — это не просто последовательность строк на фортране? Личные доводы не работают, или же я еще не придумал правильные доводы. Возможно, есть какие-то авторитетные статьи такого плана? Литература?
Никак. Все эти процессы и подходы нужны для решения тех проблем, которые возникают, если их не применять: срыв сроков, низкое качество продукта и т.п. Если предприятию на это начхать, то для руководства этой проблемы просто нет => все эти процессы никому не нужны кроме тебя.
Здравствуйте, 0x7be, Вы писали:
0>Никак. Все эти процессы и подходы нужны для решения тех проблем, которые возникают, если их не применять: срыв сроков, низкое качество продукта и т.п. Если предприятию на это начхать, то для руководства этой проблемы просто нет => все эти процессы никому не нужны кроме тебя.
Проблемы есть — низкое качество продуктов их, допустим, не волнует, а вот срыв сроков — это запросто. Можно показать, что срыв сроков есть следствие низкого качества продуктов и малых вложений в проработку продукта (архитектуры) на начальной стадии.
А по поводу профессионализма людей — согласен, в провинции все варятся в собственном соку, я имел в виду то, что проекты тянут в основном те, кто хочет работать, несмотря на обилие "трутней, демагогов и прочих личностей".
Здравствуйте, lexer_lx, Вы писали:
_>Проблемы есть — низкое качество продуктов их, допустим, не волнует, а вот срыв сроков — это запросто. Можно показать, что срыв сроков есть следствие низкого качества продуктов и малых вложений в проработку продукта (архитектуры) на начальной стадии.
Не прокатит — это будет воспринято, как ты признаешься в том, что это ты работаешь плохо, пишешь плохие программы.
Там вообще другая логика:
нужен рефакторинг — ты написал фигню, которую теперь хочешь переписать -> ты виноват
нужны тесты — ты хочешь тратить время на фигню
continuous integration — ась ? чего-чего ?
...
On 14.08.2013 9:37, lexer_lx wrote:
> Возможно, если лизать ему пятки, то по деньгам можно будет проще > договориться — но это не путь достойных.
В "донкихоты" решил вступить? Только в твоем случае, еще и без еды
окажешься.
> Что можно придумать? Как убедительно убедить в том, что программирование > — это сложно, что качественный подход — необходим, что программа сейчас > — это не просто последовательность строк на фортране? Личные доводы не > работают, или же я еще не придумал правильные доводы. Возможно, есть > какие-то авторитетные статьи такого плана? Литература?
Легче всего за рюмкой. А вот если доступа к телу нет, то делать для
начала, как говорит, бегать к нему советоваться, а потом доложить, что
облажались и в зависимости от твоей близости к его телу либо будешь
уволен и новое будет внедрять новый, либо сам.
On 14.08.2013 10:27, lexer_lx wrote:
> Проблемы есть — низкое качество продуктов их, допустим, не волнует, а > вот срыв сроков — это запросто. Можно показать, что срыв сроков есть > следствие низкого качества продуктов и малых вложений в проработку > продукта (архитектуры) на начальной стадии.
Вот когда срыв, тогда и подсовывать начальству, почему срыв. Смотришь,
через пару лет большим начальником сделают и будешь внедрять. Вот только
не пугай начальство финансовыми вложениями, к этому их нужно очень
плавно подводить (когда место для откатов найдешь). Про временные
вложения тоже не заикайся.
> А по поводу профессионализма людей — согласен, в провинции все варятся в > собственном соку, я имел в виду то, что проекты тянут в основном те, кто > хочет работать, несмотря на обилие "трутней, демагогов и прочих личностей".
Да не слушай ты местных сказочников, которые "из грязи в князи".
On 14.08.2013 10:40, klopodav wrote:
> Так лучше этими днями и неделями вместо подобной фигни втихаря > заниматься рефакторингом (не обязательно глобальным, хотя бы мелким > рефакторингом). По времени то же самое, а пользы на будущее больше.
А какие от это плюсы ТС будут?
> плясать от рисков: аргументированно рассказать, какой пипец наступит в > результате неправильного подхода (конечно, если в твоей задаче это на > самом деле так.
Не сработает, а вот коситься на него начальники будут, что вредный,
злобный и нелояльный. Рассказывать такое можно после очередного песца,
причем в таком варианте, чтобы начальство не подумало, что ты знал и не
сделал, рассказать, что блин, как хреново, что писец пришел, вот надо бы
мне заняться изучением этого песца и современных капканов на песцов, а
потом уже красивую (это главное) бумажку на стол начальнику положить.
>> Так лучше этими днями и неделями вместо подобной фигни втихаря >> заниматься рефакторингом (не обязательно глобальным, хотя бы мелким >> рефакторингом). По времени то же самое, а пользы на будущее больше. V>А какие от это плюсы ТС будут?
Плюсы довольно очевидны: раз уж несколько дней-недель все равно теряется на всякую хренотень (написание обоснований), лучше эти дни-недели потратить на работу, которая с некоторой вероятностью может облегчить жизнь в будущем. При том, что напрягаться вряд ли потребуется сильнее: усилия на неспешный рефакторинг и на выдумывание обоснований примерно одинаковые. А как распорядиться плюсами от облегчения жизни — это уже для ТС возможны варианты: либо под более эффективную работу попытаться выбить больше ЗП; либо успевать делать порученную работу быстрее, а оставшееся время отдыхать/самосовершенствоваться/делать проект для души и т.п.
>> плясать от рисков: аргументированно рассказать, какой пипец наступит в >> результате неправильного подхода (конечно, если в твоей задаче это на >> самом деле так. V>Не сработает, а вот коситься на него начальники будут, что вредный, V>злобный и нелояльный. Рассказывать такое можно после очередного песца, V>причем в таком варианте, чтобы начальство не подумало, что ты знал и не V>сделал, рассказать, что блин, как хреново, что писец пришел, вот надо бы V>мне заняться изучением этого песца и современных капканов на песцов, а V>потом уже красивую (это главное) бумажку на стол начальнику положить.
Может и сработать при правильном подходе. Например, на обычный вопрос "как дела с проектом" отвечать: "что-то мне как-то стремно, потому что...". Но это уже тонкие психологические нюансы, в которых я не особо разбираюсь
Здравствуйте, Vzhyk, Вы писали:
V>Легче всего за рюмкой.
Вот это был бы самый реальный вариант. Только доступа к телу уже нет, коллективные корпоративы у нас канули в лету очень давно...
Пожалуй это действительно бесперспективное занятие. Несколько шаблонов убеждения есть, буду стучаться с ними иногда, вдруг там кто-нибудь да откроет.
А лишнее время лучше пустить на рефакторинг.
Здравствуйте, nightcode, Вы писали:
N>если еще молодой, то беги оттуда пока не поздно...
Тема плавно перетекает к изменению объекта просвещения =)
Этот вариант рассматривается параллельно и независимо, тема интересует сама по себе, возможно, у кого-то есть подобный опыт.
Здравствуйте, lexer_lx, Вы писали:
_>Что можно придумать? Как убедительно убедить в том, что программирование — это сложно, что качественный подход — необходим, что программа сейчас — это не просто последовательность строк на фортране? Личные доводы не работают, или же я еще не придумал правильные доводы. Возможно, есть какие-то авторитетные статьи такого плана? Литература?
Пока будешь учить дураков и воевать с ветрянными мельницами вся жизнь пройдет. Ведь дураков много, а жизнь — одна. Поэтому советую не тратить зря время, а искать нормальную работу.
On 14.08.2013 12:19, klopodav wrote:
> Может и сработать при правильном подходе. Например, на обычный вопрос > "как дела с проектом" отвечать: "что-то мне как-то стремно, потому > что...". Но это уже тонкие психологические нюансы, в которых я не особо > разбираюсь
Об этом я и говорю — типичные "крысиные бега".
On 14.08.2013 12:50, lexer_lx wrote:
> Вот это был бы самый реальный вариант. Только доступа к телу уже нет, > коллективные корпоративы у нас канули в лету очень давно...
Корпоративы тут не сильно помогут, на корпоративах сильно большой риск.
Я когда-то так рискнул, и в общем выйграл, но чуть не уволили. Сейчас
оборачиваясь назад, понимаю, что по другому не смог бы поступить, но
лучше было позволить конторе сделать дерьмо — а я бы меньше нервов потратил.
> А лишнее время лучше пустить на рефакторинг.
Лучше пусти на изучение нового (в том числе и рефакторинга) и повышения
своей стоимости на рынке труда.
On 14.08.2013 12:58, lexer_lx wrote:
> Этот вариант рассматривается параллельно и независимо, тема интересует > сама по себе, возможно, у кого-то есть подобный опыт.
Есть, но это дорогостоящий опыт (с точки зрения собственных нервов при
участии в "крысиных забегах").
Это не проблема. Здесь, в ДС, тоже есть такие же предприятия. Так вот, людей, у которых:
_>процесс программирования в настоящее время некоторым образом отличается от процесса, который был 30 лет назад и заключался в кодировании прямоугольников-ромбиков-переходов?
Не приглашают даже на собеседования.
_>Знаю, что нужно валить отсюда как можно дальше и быстрее — но в силу некоторых причин пока этого сделать не могу,
А придётся.
_>Возможно, есть какие-то авторитетные статьи такого плана? Литература?
"Мифический человеко-месяц", но он уж точно его читал
Здравствуйте, lexer_lx, Вы писали:
_>в верху иерархии распределения работ/фондов оплаты труда стоит зам директора, инженер-электроник, уже несколько лет как на пенсии. _>.... _> это принципиальный для меня вопрос, попробовать просветлить этого человека, хотя бы чтобы тем, кто после меня останется, было легче.
Просветить человека в пенсионном возрасте против его воли, может, и можно, хотя очень трудно. Но только с чего Вы взяли, что он изменит поведение, будучи более просвещенным? В чем его мотив к смене подхода? Вы думаете, взяткодатели, скажем, непросвещенные и не знают, что коррупция — это плохо? Знают, но им надо проблему решить здесь и сейчас. Так и тут.
Выбери одну вещь, не спорь обо всём сразу
приходиш и говориш
1. "Пал Палыч, доверьте мне как лидеру группы сделать систему локализации на своё усмотрение"
2. Система которую я сделаю позволит легче локализировать нашу программу
3. Мне надо на работу х времени
4. Не используй слова "сложно", говри что ты хочеш сделать и какая от этого будет практическая полза
_>Так сложилось исторически, что высшее руководство предприятия — выходцы из старых времен (инженеры, электроники). То есть, о современном программировании понятия не имеют практически никакого.
когда доростёшь до их возраста и должностей поймёшь что сильно ошибался в оценках
_>Вследствие истории происхождения предприятия, схем отмывания денег, получения договоров и т.п., качество производимой продукции стоит не в приоритете
это значит что им твоё "просвящение" в куй не упёрлось. Будешь мешать им делать их дело своими хотелками — выгонят. Это же их дело а не твоё. Такчт занимайся самообразованием и вали туда где больше понравится.
_>Что можно придумать? Как убедительно убедить в том, что программирование — это сложно, что качественный подход — необходим, что программа сейчас — это не просто последовательность строк на фортране? Личные доводы не работают, или же я еще не придумал правильные доводы. Возможно, есть какие-то авторитетные статьи такого плана? Литература?
— программирование это не сложней проектирования трубопроводов
— качественный подход в данном случае не нужен
— программа это просто последовательность строк
— чтобы личные доводы заработали нужно сделать что-то полезное для других а не для своего самообразования
_И первая же проблема — как убедить его в том, что процесс программирования в настоящее время некоторым образом отличается от процесса, который был 30 лет назад и заключался в кодировании прямоугольников-ромбиков-переходов?
Если это не просто эмоции, то, пожалуйста, убедите в этом меня.
Здравствуйте, Victor Ivanidze, Вы писали:
VI>_И первая же проблема — как убедить его в том, что процесс программирования в настоящее время некоторым образом отличается от процесса, который был 30 лет назад и заключался в кодировании прямоугольников-ромбиков-переходов?
VI>Если это не просто эмоции, то, пожалуйста, убедите в этом меня.
Имеем: куча проектов на mfc, wxWidgets, Qt, WinApi. Для текста используются char*, CString, QString, wxString — как попало и где попало.
Просто замена текста в кавычках не годится — нужна кодировка, отличная от однобайтной.
Но допустим, что мы нашли способ просто менять текст в кавычках и таким образом получать проект, локализованный на требуемый язык. Процесс перевода будет проходить в несколько этапов — получаем первый вариант, подставляем в кавычки, отдаем заказчику, он смотрит что все выглядит как надо (естественно будет куча замечаний и править текст в кавычках придется много раз). В дальнейшем появятся другие языки. Придется снова править все тексты (вносить в них ошибки, естественно, мы же не роботы).
Можно реализовать подсистему локализации, продумать гибкий интерфейс, использовать ее в других проектах, существующих и будущих. Модификация исходных кодов программ будет сделана один раз, и последующие добавления новых языков коды программ не затронут.
В первом случае мы "меняем текст в кавычках", "обезьянья работа", как выражается босс. В нашем случае — универсальный многофункциональный модуль, который может сэкономить много часов нашей работы.
Пример с переводами — просто пример. Можно придумать способ, например, держать тексты в файлах в unicode, загружать их и перекодировать в однобайтную кодировку в соответствии с нужным языком, и не править существующий код. Это не столь важно.
Возможно, я не совсем точно выразился, когда говорил о ромбиках — но суть такая, что нас пытаются заставить решать любую задачу "в лоб", не смотря вперед ни на шаг. По мере возможности мы пытаемся делать "хорошо" — но не всегда успеваем, иногда узкие временные рамки заставляют делать "в лоб". Но потом с нас же и спрашивают — почему все так плохо, почему не успеваем, куда уперлись, ведь сделали же ранее, почему теперь надо переделывать, ведь ромбики же, переходы, какая разница, там программа, тут программа...
Здравствуйте, lexer_lx, Вы писали:
_>Здравствуйте, Victor Ivanidze, Вы писали:
VI>>_И первая же проблема — как убедить его в том, что процесс программирования в настоящее время некоторым образом отличается от процесса, который был 30 лет назад и заключался в кодировании прямоугольников-ромбиков-переходов?
VI>>Если это не просто эмоции, то, пожалуйста, убедите в этом меня.
_>В первом случае мы "меняем текст в кавычках", "обезьянья работа", как выражается босс. В нашем случае — универсальный многофункциональный модуль, который может сэкономить много часов нашей работы.
этот "универсальный многофункциональный модуль" криво написанный студентом добавит сотни проблем из-за твоей неопытности (первый блин комом обычно). Потом, когда ты сбежишь в москву и на твоё место возьмут такого же студента за гроши, ему будет трудно всё твоё добро переписывать заново.
А обезьянью работу сможет выполнить любой низкоквалифицированный работник. Время твоё стоит дёшево, посидишь лишний десяток часов и сделаешь.
Твоё начальство это понимает, ты поймёшь через пяток лет тоже.
PS
в описании проблем не увидел никаких отличий от того что было 10, 20, 30 лет назад. Да и в непрограммировании примерно так же — дешёвый труд снижает потребность в автоматизации, это закон.
Здравствуйте, lexer_lx, Вы писали:
_>Здравствуйте, Victor Ivanidze, Вы писали:
VI>>_И первая же проблема — как убедить его в том, что процесс программирования в настоящее время некоторым образом отличается от процесса, который был 30 лет назад и заключался в кодировании прямоугольников-ромбиков-переходов?
VI>>Если это не просто эмоции, то, пожалуйста, убедите в этом меня.
....
Не убедили. Всё вами описанное есть ваша внутрифирменная специфика (или политика), которая не имеет никакого отношения к вашему громкому утверждению про процесс программирования. Если бы у вас был разрешён только Fortran в качестве языка разработки и текстовый редактор MultiEdit как среда разработки, проблемы были бы такие же.
Здравствуйте, Victor Ivanidze, Вы писали:
>Не убедили. Всё вами описанное есть ваша внутрифирменная специфика (или политика), которая не имеет никакого отношения к вашему громкому утверждению про процесс программирования.
Ну вот, уже двоих нужно убеждать =)
Еще раз повторяю, что я не совсем точно выразился о процессе программирования. Суть состоит в том, чтобы искать более качественные подходы к процессу разработки ПО. Вместо 10к строк кода написать 6к, которые будут понятнее и гораздо проще поддерживаемые при наличии должной документации. Но с немного большими затратами на реализацию. Както так. По сути — да, это все тот же набор геометрических фигур.
А что касается 30-летнего прошлого, то я очень сомневаюсь в том, использование концепций ООП, паттернов проектирования в том или ином видах и прочих прелестей современного процесса разработки ПО было в то время повсеместным.
>Если бы у вас был разрешён только Fortran в качестве языка разработки и текстовый редактор MultiEdit как среда разработки, проблемы были бы такие же.
Да, потому как исходная предпосылка — максимальный уровень экономии. И эта экономия нашла свой выход в непрофильном для предприятия направлении. Потому необходимо обосновать, к чему может привести дальнейший отказ от более качественного подхода к написанию ПО, чтобы экономия свернула на другую ветку.
Здравствуйте, lexer_lx, Вы писали:
_>Что можно придумать? Как убедительно убедить в том, что программирование — это сложно, что качественный подход — необходим, что программа сейчас — это не просто последовательность строк на фортране? Личные доводы не работают, или же я еще не придумал правильные доводы. Возможно, есть какие-то авторитетные статьи такого плана? Литература?
От правильного выбора слов на 100% зависит произведённый эффект.
Надо поставить себя на место этого руководителя. Представь: тебе надо выполнять задачу, а к тебе приходит вьюноша с горящими глазами и начинает грузить тебя неведомой фигнёй да ещё с намёком, что твои знания устарели. Тебе бы это понравилось? Вот и ему нет.
Ему что надо — чтобы задача была решена качественно и в срок. И ему абсолютно не интересно вникать в детали реализации. Не надо ему говорить о супер-пупер системе локализации. Скажи: придумал простое и дешевое решение, которое позволит избавится от проблемы локализации навсегда. Это для руководителя как бальзам на душу. Только это должно быть действительно простое и дешевое решение, а не какой-нибудь универсальный всемогутор. И желательно с цифрами. Например: сейчас процесс локализации занимает 1 месяц и правка багов на 3 месяца, потом будет занимать 1 неделю и править баги не надо. А на реализацию самого решения надо 3 дня. Вот это будет конструктивный разговор.
Здравствуйте, Dufrenite,
D>Например: сейчас процесс локализации занимает 1 месяц и правка багов на 3 месяца, потом будет занимать 1 неделю и править баги не надо. А на реализацию самого решения надо 3 дня.
А если — "на реализацию самого решения надо 3 месяца"? А если при обещанных 3 месяцах реальный срок разработки и правки багов в этом самом "простом и дешевом решении" будет уже месяцев этак 10?
Здравствуйте, Vlad_SP, Вы писали:
V_S>Здравствуйте, Dufrenite,
D>>Например: сейчас процесс локализации занимает 1 месяц и правка багов на 3 месяца, потом будет занимать 1 неделю и править баги не надо. А на реализацию самого решения надо 3 дня.
V_S>А если — "на реализацию самого решения надо 3 месяца"?
Я вас умоляю. Загрузить и распарсить xml-файл за 3 месяца?
V_S>А если при обещанных 3 месяцах реальный срок разработки и правки багов в этом самом "простом и дешевом решении" будет уже месяцев этак 10?
В этом случае разработчик, как настоящий самурай, обязан совершить харакири.
V_S>>Здравствуйте, Dufrenite,
V_S>>А если при обещанных 3 месяцах реальный срок разработки и правки багов в этом самом "простом и дешевом решении" будет уже месяцев этак 10?
D>В этом случае разработчик, как настоящий самурай, обязан совершить харакири.
У нас возможны более действенные меры — отправят реализовывать непосредственно на объект, а там радиационный фон, быстренько все за пару дней сделаем и без багов =)
Здравствуйте, lexer_lx, Вы писали:
_>У нас возможны более действенные меры — отправят реализовывать непосредственно на объект, а там радиационный фон, быстренько все за пару дней сделаем и без багов =)
, в провинции не только с деньгами проблема, там вообще с it проблема, хочешь расти как специалист — валить в крупный город, без вариантов (потом можно и на удаленку)
