Wink

Cibtor писал:

Проблема в том, что многие не понимают, что профессия программиста -- это НЕ такая же обычная профессия, как и, например, механик. Это творческая профессия (аналогично как и, например, дизайнер). Если есть вдохновение то прогу можно написать за несколько часов, а если нет, то и пару дней можно просидеть без толка.

Вдохновляться вы будете на OS проектах. Когда же у вас есть план и цель, это неуместно.
Механик тоже может вдохновится и создать что-нибудь этакое, однако в большинстве случаев приходится менять масло.

Последний раз редактировалось: Nic (15/11/19 в 10:38), всего редактировалось 1 раз

ghood писал:

Вдохновляться вы будете на OS проектах. Когда же у вас есть план и цель, это неуместно. Механик тоже может вдохновится и создать что-нибудь этакое, однако в большинстве случаев приходится менять масло.

Не путайте механика и инженера-конструктора. Механику ничего не нужно придумывать, а нужно только выполнять работу согласно схемы конструкции. А обычно заказчики говорят типа такого: "я хочу что бы прога делала то-то, и что бы это было сделанно побыстрее". За все время я видел только одно красиво написанное ТЗ, где было расписанно буквально все, начиная от того где какая кнопка расположена, и заканчивая, что скрипт должен делать если произойдет сбой.
Если ты хочешь, что бы все было сделанно в указанный срок и подано тебе в красивой упаковке, то не жми бабки, и обращайся в офф-лайн контору, заключай с ней договор и работай. Но при этом учитывай, что прога тебе при этом обойдется не в 300 баксов, а в 1500, и делать ее будут не пару недель (вкалывая до 4 утра), а полгода.
Данная тема обычно поднимается с периодичностью раз в полгода, и наверное будет подниматься еще ни раз .
И на последок совет от меня: "Ни что так не дисциплинирует человека, как предоплата".

Cibtor писал:

И на последок совет от меня: "Ни что так не дисциплинирует человека, как предоплата".

В смысле чтобы программеры залог давали? Я - за

stuchi mne, u menya est' nuznye ludi

Прикольно конечно читать, но это надо в трёп, а не в Работа.
Писать можно транслитом, русскими или вообще не писать.
Важно кто есть человек, а не то что он вам говорит в ответ на ваши глупые (с его точки зрения) вопросы.

Cibtor писал:

Не путайте механика и инженера-конструктора.

Пральна, программист не является в 90% времени инженером, я является механиком . Поэтому путать не нужно.

Cibtor писал:

А обычно заказчики говорят типа такого: "я хочу что бы прога делала то-то, и что бы это было сделанно побыстрее". За все время я видел только одно красиво написанное ТЗ, ...skipped... Если ты хочешь, что бы все было сделанно в указанный срок и подано тебе в красивой упаковке, то не жми бабки, и обращайся в офф-лайн контору, заключай с ней договор и работай.

Обычно такие слова говорят о непрофессионализме разработчика. Человек должен просто хорошо делать свою работу, а не искать причины почему её трудно сделать.

Есть желание -- тысяча возможностей, нет желания -- тысяча причин (С) не знаю кто, взял у Вада

Цитата:

Есть желание -- тысяча возможностей, нет желания -- тысяча причин (С) не знаю кто, взял у Вада

+10

И как всегда заказчики лучше программистов знают что и как надо программировать

Шли бы вы господа пинать булочника на предмет "хочу вот точно такую же булочку но корочка должна быть справа и с тремя дырочками вот тут, тут и тут".

Заодно можете пройтись в автосалон и кастомизировать машину под себя, потом посмотрев насколько вырастет цена, объяснить что там одни непрофессионалы и уйти искать человека кто сделает точно такое же, но дешевле, при этом объясняя "так, салончик мне как у купера, движок как у ауди и главное проходимость что бы везде была, ну там по полям, лесам. И главное на трассе под 200. Вобщем фигня всякая, несложно же, другие же делают."

Stek писал:

И как всегда заказчики лучше программистов знают что и как надо программировать

Заказчики, как и программеры, бывают разные
Вообще дискуссия пришла к обобщениям, а это не есть хорошо.

Цитата:

Заодно можете пройтись в автосалон и кастомизировать машину под себя, потом посмотрев насколько вырастет цена

Не совсем корректный пример.
Есть предложение - есть спрос. Если программера не устраивает сумма которую готов заплатить заказчик - не надо браться, можно делать другие, более прибыльные заказы (если таковые есть).

ghood писал:

Пральна, программист не является в 90% времени инженером, я является механиком . Поэтому путать не нужно.

Кстати очень распространенное заблуждение. На самом деле 80% времени занимает панирование, проектирование и отладка. И только 20% - собственно "механическое" кодирование.

Цитата:

Вообще дискуссия пришла к обобщениям, а это не есть хорошо.

любая дискуссия к такому приходит когда две стороны сталкиваются, по крайней мере на этом форуме

Топиков нормальных на мастере мало становится, вот и отрывается народ в подходящих, где не совсем тупой флейм как "продам дамен за пяцот"

luden_ писал:

Кстати очень распространенное заблуждение. На самом деле 80% времени занимает панирование, проектирование и отладка. И только 20% - собственно "механическое" кодирование.

Не совсем понял про какое заблуждение говорится и почему сюда включили отладку. Специально поднял навскидку несколько старых таймшитов. Для них утверждение о 80% времени на планирование и проектирование не верно. Задача программиста -- программировать, решать поставленные задачи наиболее оптимальным способом. Все разговоры о вдохновении и т п. не больше чем попытка оправдать свою лень

Дискуссия-то идёт о сравнении профессии программиста с профессией механика. Все нюансы взаимоотношений с заказчиком, проблемы постановки задач, оценки сроков и т д мне хотелось бы оставить в стороне, это другая тема.

Стек например наелся опыта с заказчиками, которые слабоваты в постановке задачи и не могут точно определить свои потребности и сопоставить их с финансовыми возможностями (если я правильно помню), поэтому у него своё видение проблемы

Цитата:

Топиков нормальных на мастере мало становится, вот и отрывается народ в подходящих

+1 очень мало.

п.с. Даёшь "зарплату админа" на мастере

ghood писал:

Не совсем понял про какое заблуждение говорится и почему сюда включили отладку. Специально поднял навскидку несколько старых таймшитов. Для них утверждение о 80% времени на планирование и проектирование не верно. Задача программиста -- программировать, решать поставленные задачи наиболее оптимальным способом. Все разговоры о вдохновении и т п. не больше чем попытка оправдать свою лень

Да причем тут лень-то Просто сам код пишется ну очень быстро по сравнению с его проектированием и планированием, что в свою очередь примерно равнозначно по времени последующей отладке.

luden_ писал:

Да причем тут лень-то Просто сам код пишется ну очень быстро по сравнению с его проектированием и планированием, что в свою очередь примерно равнозначно по времени последующей отладке.

Да это все так...
Однако все-таки один вопрос остается: поддаются-ли эти этапы планированию? Я слонен полагать что да.

Man писал:

Да это все так... Однако все-таки один вопрос остается: поддаются-ли эти этапы планированию? Я слонен полагать что да.

Конечно поддаются. Риски тоже по идее должны быть запланированы. Другое дело, что на небольших проектах риски могут дать до 1000% увеличения времени на проект, поэтому врядли они во первых планируются, во вторых учитываются. На крупных проектах подобные дизастеры по идее минимизируются объемами, протяженностью, и командой.
А на мелких shit happens будет скорей-всего постоянно. Я, например, прикидываю время за которое я сделаю и потом тупо умножаю его на три. Собственно даже при таком бывает что немного не укладываешься.

luden_ писал:

А на мелких shit happens будет скорей-всего постоянно. Я, например, прикидываю время за которое я сделаю и потом тупо умножаю его на три. Собственно даже при таком бывает что немного не укладываешься.

Вот о том и речь...
С одной стороны, заказчик не может сам определить время которое требуется программеру на выполнение работы. В этом топике много раз прозвучало это в той или иной форме.
С другой стороны, зачастую программеры сами не могут этого сделать адекватно, как показывает практика. Собсно ты только что это подтвердил
И вот тут уже на мой взгляд и определяется насколько та или иная задержка обусловлена объективными трудностями или банальной ленью разработчика.
При том что работа действительно творческая, нельзя списывать любое распиздяйство на "отсутсвие вдохновения".
В той или иной степени мы все творческой работой занимаемся, и заказчики в том числе. Но нельзя работать нормально, когда все планирование идет к черту из-за того что программер не считает что увеличение оговоренных сроков на 20-30-50-200% это большая проблема.

Man писал:

Вот о том и речь... С другой стороны, зачастую программеры сами не могут этого сделать адекватно, как показывает практика. Собсно ты только что это подтвердил

Man писал:

Но нельзя работать нормально, когда все планирование идет к черту из-за того что программер не считает что увеличение оговоренных сроков на 20-30-50-200% это большая проблема.

Слушай, ну при таком положении - это ошибка заказщика:
1) возможно не тот программер
2) возможно не грамотно подготовленное задание
3) навереное самое главное - возможно не поставленный work routine (документация, отчеты, code review итд итд).

Потому, что понять, что человек не укладывается в сроки можно в принципе уже где-то на середине. Тогда еще можно предпринять какие-то меры, кнута пряника или привлечения дополнительного человеческих ресурсов.

Нужно навреное выработать нормальные методы взаимодействия с программером (ну или программер должен сам их предложить) чтобы работа была прозрачной. Тогда хлявить и забивать значительно сложнее в том числе и в психологическом смысле.

Можно мотивировать премией за здачу в срок (дико звучит да? ). Впринципе тоже вполне рабочий вариант.

luden писал:

Слушай, ну при таком положении - это ошибка заказщика: 1) возможно не тот программер 2) возможно не грамотно подготовленное задание 3) навереное самое главное - возможно не поставленный work routine (документация, отчеты, code review итд итд).

Возможно-то много что...
Берем рядовой пример. Заказчик ищет программера на выполнение какого-то проекта. Работа по "удаленке".
ТЗ составлено настолько насколько заказчик представляет в данные момент проект. Обговаривают сумму и сроки.
В результате - выходит ерунда или со сроками или по результату.

"Возможно" может быть повторюсь много, даже на пункты поставленные тобой есть контраргументы:
1) Сроки обговаривались
2) При это разработчик видел ТЗ и видел то насколько грамотно оно было составлено.
Т.е. я не очень понимаю этих аргументов - "заказчик плохо поставил задачу". Если плохо, то почему исполнитель за нее взялся? Или почему не поставил в известность заказчика о том что задача поставленная в таком виде потребует до ХХ% увеличения срока?
В любом случае - с момента как началось обсуждение проекта, программер не является неким сторонним лицом которое в любом случае "непричем".
Одно дело если тебя спрашивают "за сколько ты нарубишь машину дров", ты отвечаешь "за 3 дня", а потом тебе привозят не машину, а вагон, а топор дают пластмассовый. А другое дело если ты сам съездил на лесопилку, набрал там чурок и сам купил топор

Цитата:

Потому, что понять, что человек не укладывается в сроки можно в принципе уже где-то на середине. Тогда еще можно предпринять какие-то меры, кнута пряника или привлечения дополнительного человеческих ресурсов. Нужно навреное выработать нормальные методы взаимодействия с программером (ну или программер должен сам их предложить) чтобы работа была прозрачной. Тогда хлявить и забивать значительно сложнее в том числе и в психологическом смысле.

Согласен на все 100 и с этим и с 3им пунктом из которого это вытекает. Отчетность и чекпоинты это ключ. Но большинство не любят такой подход. Типа как было написано выше: с такими требованиям "не жми бабки, и обращайся в офф-лайн контору"

Man писал:

Возможно-то много что... Берем рядовой пример. Заказчик ищет программера на выполнение какого-то проекта. Работа по "удаленке". ТЗ составлено настолько насколько заказчик представляет в данные момент проект. Обговаривают сумму и сроки. В результате - выходит ерунда или со сроками или по результату.

Man писал:

Одно дело если тебя спрашивают "за сколько ты нарубишь машину дров", ты отвечаешь "за 3 дня", а потом тебе привозят не машину, а вагон, а топор дают пластмассовый. А другое дело если ты сам съездил на лесопилку, набрал там чурок и сам купил топор

Твоя логика понятна, и я с ней согласен. Просто иногода бывают моменты, когда в процесе чурки оказывается должны быть шестиугольными, а топор на солнечных батарейках ;) Но это частности.

А тут да. В этом случае со стороны программиста должно было быть потрачено время на исследование инструментов и проблемы ими решаемой. Либо программер должен досконально знать то с чем придется работать.

Тут нужно подумать как заказщику этот момент проконтролировать и не упустить. Не резюме же с человека требовать.

Man писал:

Согласен на все 100 и с этим и с 3им пунктом из которого это вытекает. Отчетность и чекпоинты это ключ. Но большинство не любят такой подход.

Значит нужно найти компромисные временные отрезки для отчетов (имхо раз в 3-4 дня самое то). И SVN/CVS must have, с коммитами в теже временные промежутки.

Если кому-то такой подход не подходит... ну даже не знаю. Имхо самому даже проще, когда планы и отчеты пишешь. А про удаленые системы контроля версий я вообще молчу.

Моё ИМХО:
1. Чтобы решить задачу в срок нужно её понять, для этого порой требуется 20% времени от решения задачи.
2. Любую задачу можно решить в срок (Королёв чтоб запустить ракету ночами не спал), важно лишь иметь желание и весомые аргументы.
3. Желание и аргументы зависят от денег которые обещаны и интересности задачи.
4. В решении любой задачи может возникнуть форс - мажор, которого ни закачик ни прогер знать на этапе обсуждения ТЗ, сроков и суммы не могли знать, и потому надо терпимее относиться и внятно такие моменты объяснять.