Возникла следующая проблема.
Работаю в бывшем гос предприятии, теперь — ЧАО, сфера деятельности — автоматизация тех процесса (АЭС, ЖД — преимущественно АЭС, программно-технические комплексы управления различными узлами станций, в том числе и критически важными).
Так сложилось исторически, что высшее руководство предприятия — выходцы из старых времен (инженеры, электроники). То есть, о современном программировании понятия не имеют практически никакого.
Вследствие истории происхождения предприятия, схем отмывания денег, получения договоров и т.п., качество производимой продукции стоит не в приоритете — стандартный процесс формального выполнения требований в нереальные сроки. В силу того, что предприятие территориально находится в неблагоприятном районе с точки зрения выбора работы (для программистов альтернативы нету в принципе — кроме как мигрировать в другие города или фрилансить) — есть много хороших спецов, которые кое-как тянут на себе проекты.
Поражает тот факт, что у всего многообразия различных комиссий (МАГАТЭ и прочих) не возникают вопросы по поводу отсутствующего у нас отдела тестирования. Хотя, вследствие вышеизложенного, уже не возникают.
Но речь не об этом, а вот о чем: в верху иерархии распределения работ/фондов оплаты труда стоит зам директора, инженер-электроник, уже несколько лет как на пенсии. Я с недавнего времени получил в подчинение пару сотрудников, и в круг моих задач добавилось выбивание работы и денег у этого человека. И первая же проблема — как убедить его в том, что процесс программирования в настоящее время некоторым образом отличается от процесса, который был 30 лет назад и заключался в кодировании прямоугольников-ромбиков-переходов?
Вот конкретная работа: есть у нас несколько проектов, некоторые — крупные, написанные уже довольно давно (C++, MFC, wxWidgets, Qt). Все — с русскоязычным интерфейсом. Никакого юникода (то есть, нагромождение строковых типов — char*, CString и т.п.). Необходимо адаптировать исходники к локализации на другие языки. Кода много — в перспективе светит адова работенка. По мнению замдиректора — это "обезьянья работа", заключающаяся в тупой замене содержимого кавычек новым текстом. О разных типах, о универсальной подсистеме локализации (при добавлении нового языка — будем копировать проект и еще раз менять содержимое кавычек) он слышать не желает. Тычет свой фортран, на котором он текст в кавычках очень просто когда-то выводил и там нет ничего сложного. Это просто пример, аналогичная ситуация возникает постоянно. Никакие, повторяю, никакие доводы не работают, даже если мы ему покажем наши исходники — его логика элементарна (текст -> кавычки — замена всего что в кавычках -> если у нас не так, то мы дебилы).
Возможно, если лизать ему пятки, то по деньгам можно будет проще договориться — но это не путь достойных.
В итоге, вместо того, чтобы полноценно работать, люди днями и неделями занимаются исследовательско-литературной работой на тему "Придумай обоснование".
Знаю, что нужно валить отсюда как можно дальше и быстрее — но в силу некоторых причин пока этого сделать не могу, да и это принципиальный для меня вопрос, попробовать просветлить этого человека, хотя бы чтобы тем, кто после меня останется, было легче.
Что можно придумать? Как убедительно убедить в том, что программирование — это сложно, что качественный подход — необходим, что программа сейчас — это не просто последовательность строк на фортране? Личные доводы не работают, или же я еще не придумал правильные доводы. Возможно, есть какие-то авторитетные статьи такого плана? Литература?
Здравствуйте, lexer_lx, Вы писали:
_>В силу того, что предприятие территориально находится в неблагоприятном районе с точки зрения выбора работы (для программистов альтернативы нету в принципе — кроме как мигрировать в другие города или фрилансить) — есть много хороших спецов, которые кое-как тянут на себе проекты.
первый нюанс насчет хороших спецов — я тоже, пока не начал работать в столице думал, что очень крут , в провинции не только с деньгами проблема, там вообще с it проблема, хочешь расти как специалист — валить в крупный город, без вариантов (потом можно и на удаленку)
_>Что можно придумать? Как убедительно убедить в том, что программирование — это сложно, что качественный подход — необходим, что программа сейчас — это не просто последовательность строк на фортране? Личные доводы не работают, или же я еще не придумал правильные доводы. Возможно, есть какие-то авторитетные статьи такого плана? Литература?
ответ простой — никак, проблема в том, что на твоем предприятии (я сталкивался с такими, очень узнаваемо) качественный код просто никому не нужен — как-то работает и хрен с ним
Здравствуйте, lexer_lx, Вы писали:
_>Так сложилось исторически, что высшее руководство предприятия — выходцы из старых времен (инженеры, электроники). То есть, о современном программировании понятия не имеют практически никакого.
Никак. Не мечи бисер, подумай о своем профессиональном развитии в другом месте.
Здравствуйте, lexer_lx, Вы писали:
_>Что можно придумать? Как убедительно убедить в том, что программирование — это сложно, что качественный подход — необходим, что программа сейчас — это не просто последовательность строк на фортране? Личные доводы не работают, или же я еще не придумал правильные доводы. Возможно, есть какие-то авторитетные статьи такого плана? Литература?
Никак. Все эти процессы и подходы нужны для решения тех проблем, которые возникают, если их не применять: срыв сроков, низкое качество продукта и т.п. Если предприятию на это начхать, то для руководства этой проблемы просто нет => все эти процессы никому не нужны кроме тебя.
Здравствуйте, 0x7be, Вы писали:
0>Никак. Все эти процессы и подходы нужны для решения тех проблем, которые возникают, если их не применять: срыв сроков, низкое качество продукта и т.п. Если предприятию на это начхать, то для руководства этой проблемы просто нет => все эти процессы никому не нужны кроме тебя.
Проблемы есть — низкое качество продуктов их, допустим, не волнует, а вот срыв сроков — это запросто. Можно показать, что срыв сроков есть следствие низкого качества продуктов и малых вложений в проработку продукта (архитектуры) на начальной стадии.
А по поводу профессионализма людей — согласен, в провинции все варятся в собственном соку, я имел в виду то, что проекты тянут в основном те, кто хочет работать, несмотря на обилие "трутней, демагогов и прочих личностей".
Здравствуйте, lexer_lx, Вы писали:
_>Проблемы есть — низкое качество продуктов их, допустим, не волнует, а вот срыв сроков — это запросто. Можно показать, что срыв сроков есть следствие низкого качества продуктов и малых вложений в проработку продукта (архитектуры) на начальной стадии.
Заходи с тематики решения тех проблем, которые реально парят начальство, тогда имеешь шанс быть услышанным.
_>И первая же проблема — как убедить его в том, что процесс программирования в настоящее время некоторым образом отличается от процесса, который был 30 лет назад и заключался в кодировании прямоугольников-ромбиков-переходов?
Я тебе страшную тайну открою: принципиально ничего не изменилось, все то же кодирование прямоугольников-ромбиков-переходов, разница только в синтаксисе языков, правилах расстановки стрелочек между прямоугольниками-ромбиками и навороченных IDE для кодирования прямоугольников-ромбиков.
_>В итоге, вместо того, чтобы полноценно работать, люди днями и неделями занимаются исследовательско-литературной работой на тему "Придумай обоснование".
Так лучше этими днями и неделями вместо подобной фигни втихаря заниматься рефакторингом (не обязательно глобальным, хотя бы мелким рефакторингом). По времени то же самое, а пользы на будущее больше.
_>Что можно придумать? Как убедительно убедить в том, что программирование — это сложно, что качественный подход — необходим, что программа сейчас — это не просто последовательность строк на фортране?
Пытаться убедить в том, что кошерные подходы к программированию лучше некошерных — дохлый номер. Если надо человека в чем-то убедить, то надо плясать от рисков: аргументированно рассказать, какой пипец наступит в результате неправильного подхода (конечно, если в твоей задаче это на самом деле так. А может, там и правда качество кода пофиг.)
Здравствуйте, 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>Легче всего за рюмкой.
Вот это был бы самый реальный вариант. Только доступа к телу уже нет, коллективные корпоративы у нас канули в лету очень давно...
Пожалуй это действительно бесперспективное занятие. Несколько шаблонов убеждения есть, буду стучаться с ними иногда, вдруг там кто-нибудь да откроет.
А лишнее время лучше пустить на рефакторинг.
Здравствуйте, lexer_lx, Вы писали:
_>Пожалуй это действительно бесперспективное занятие. Несколько шаблонов убеждения есть, буду стучаться с ними иногда, вдруг там кто-нибудь да откроет. _>А лишнее время лучше пустить на рефакторинг.
если еще молодой, то беги оттуда пока не поздно, оглянуться не успеешь — жена, дети, дача... и хрен потом куда денешься
Здравствуйте, 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 лет назад и заключался в кодировании прямоугольников-ромбиков-переходов?
Не приглашают даже на собеседования.
_>Знаю, что нужно валить отсюда как можно дальше и быстрее — но в силу некоторых причин пока этого сделать не могу,
А придётся.
_>Возможно, есть какие-то авторитетные статьи такого плана? Литература?
"Мифический человеко-месяц", но он уж точно его читал