На сайте ведутся работы Контекст "Проблемы, возникающие у программиста при работе с Заказчиком" | Нематериальное стимулирование, компенсационные пакеты | Бизнес-форум TRIZ-RI
9737
СОГЛАСЕН С ОБРАБОТКОЙ ЛИЧНЫХ ДАННЫХ
Все категории » Нематериальное стимулирование, компенсационные пакеты » Что мешает программистам IT-отделов…

Контекст "Проблемы, возникающие у программиста при работе с Заказчиком"

Ваши данные (просмотреть)
в избранные темы
Политика конфиденциальности

Обсуждения-аналоги

Скрыть / Показать Сортировать по дате
Создать аналогичное обсуждение...

Авторы

Скрыть / Показать
2002-12-16 11:31:02
Виталий Онегов » Всем

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

По поводу плохих и хороших программистов и создания проектов.

Мне кажется, что 50% вины за несвоевременно или неправильно сделанный проект, который к тому же не уложился в бюджет - это вина начальства фирмы, для которой это все делается. Почему? Да потому, что обычно хочется много всего за небольшие деньги и быстро. А по мере продвижения проекта вдруг оказывается, что много-много чего не предусмотрели, забыли, придумали - вот она, дополнительная функциональность, переделка уже сделанного и т.д. и т.п. Опять же, за небольшие деньги кого наймешь? Правильно, программистов из пункта 1 (см. выше). На пункт 2 не хватает маней :) Результат следует очевидный - если чего и сделано, то ужас как.

Это конечно все в кратце.......

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

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

И по поводу ответственности за сделанное: стоит взглянуть на технику, бытовую или какую другую, сделанную в России, то возникает мысль: если инженер должен нести ответственность за все это, то вся российская промышленность останется без инженеров и т.п. - потому что за ЭТО казнить надо, а не выговоры делать. Но раз все на месте - значит ответственность никто не несет :)

Извиняюсь за сумбурность, что-то сегодня мысли вперемешку ходят :))

[Показать все ответы на это сообщение]
2002-12-16 12:27:14
Vladimir Kirichenko » Сергей В. Сычев
Доброго!

Ответственность за рухнувший мост несет иманно "Проектировщик". А не Вася, который бетон лопатой мешал.

Вы же сами говорите о модели Архитектор-Кодеры, и сами же говорите, что ответсвенность должны нести программисты.

Васю который бетон лопатой мешал никто не обвинит в том, что мост рухнул. Следовательно в случае модели Архитектор-Кодеры только архитектор виноват. А обвинить вы в данном случае хотите всех. Так вот за такую ответственонсть надо платить адекватное вознаграждение. Нельзя требовать от программиста, который получает ооочень маленькие деньги относительно стоимости проекта, чтобы он отвечал за провал проекта. Нельзя требовать от конторы, которая выполняла реализацию билинга мобильного провайдера и получила фиксированную оплату ответственности за убытки в случае, если билинг глюконет. Единственный справедливый контракт подобного рода это контракт, который дает право участия в прибыли. А это уже очень другие деньги. Ответственность покупаеться за очень другие деньги. А на это ни один заказчик не пойдет. Так вот пока все заказыветься по дешевке - получаеться соответствующее качество. Пока заказчик хочет все(хотя обьяснить что именно не может), по быстрому, и за дешево - он будет получать соответствующее качество. А поскольку кушать всем хочеться - ему будут предоставлять свои услуги по реализацию c этими условиями. Это реальность.
[Показать все ответы на это сообщение]
2002-12-17 13:49:51
Сергей В. Сычев » Vladimir Kirichenko

Да, я согласен с тем доводом, что при разделении функций "Архитектор - Кодер" большая ответственность (в определенных случаях, вся) ложится на "архитектора".

Правда, я бы эту цепочку изложил чуть иначе: "Архитектор - Технолог - Кодер", либо "Архитектор - Технолог - Кодер - Контролер" (думаю лет через 7 такая модель станет привычной). То есть, программирование в своем развитии те же этапы, что и другие специальности.

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

Я просто изложил факты:

Факт 1: "Ошибок в программном обеспечении очень много"

Факт 2: "Есть разделяемая многими (но не всеми) "теория" о том, что наличие ошибок это нормально. Эта "теория" временная.

Факт 3: "Есть альтернативная точка зрения. И она более продуктивна".

Факт 4: "В иных отраслях аналогичные споры уже были.

Например, в медицине спор о качестве качестве работы врача и о его ответственности был актуален в 1820-30-е годы. (При этом, я хотел бы обратить Ваше внимание на тот факт, что не только весь организм человека, но большинство органов - это более сложные и по сей день менее понятные системы, чем Windows). В начале 19 века считалось, что "раз человек так сложен", то, когда он умирает в больнице - это совершенно нормально. Если выжил - это победа врача, если умер - так угодно богу. См., например, статью "Победа для побежденных".

С Уважением,

[Показать все ответы на это сообщение]
2002-12-17 22:05:09
Кирилл Лебедев » Vladimir Kirichenko
> Ответственность за рухнувший мост несет иманно
>"Проектировщик". А не Вася, который бетон лопатой мешал.
> Вы же сами говорите о модели Архитектор-Кодеры, и сами же
> говорите, что ответсвенность должны нести программисты.

Мне кажется, ответственность должны нести все: и Архитектор системы, и продюсер, и мэнеджеры, и программисты. А то получается, как всегда, - перекидывание ответственности друг на друга.
Если каждый из этой цепочки "Архитектор - продюссер - мэнеджер - программист" научится брать ответственность на себя, а не перекладывать ее на других, качество программных продуктов, по моему мнению, возрастет.
[Показать все ответы на это сообщение]
2002-12-18 10:50:42
Grigoriev Alexey » Кирилл Лебедев
>>сли каждый из этой цепочки "Архитектор - продюссер - мэнеджер - программист" научится брать ответственность на себя..........

Вот поэтому, так все и работает. QA - даже не предусмотрен, а ведь, отвественный за QA - и есть _самый главный виноватый_ по ВСЕМ вопросам качества.
[Нет ответов на это сообщение]
2002-12-18 15:49:45
Георгий Соколов » Всем
Уважаемые коллеги!
 
Профессия программист болеет рядом болезней, свойственных:
а) молодым профессиям
(сверхреклама возможностей, низкое в среднем качество, отсутствие понятных критериев оценки и контроля качества и т.п.)
б) творческим профессиям
(завышенная самооценка, привычка постоянно "шаманить", сопротивление любой "технологизации" процесса работы и т.п.)
 
Программистам было бы полезно посмотреть на ситуацию "со стороны". Например, как схожие проблемы во взаимоотношениях между Заказчиками и Исполнителями возникали и продолжают возникать: 
- в рекламной деятельности:
"Бранятся или тешатся? Взаимопретензии рекламодателей и рекламистов" (проанализирован опыт Коллег из более чем 20 городов);
- в выставочной деятельности:
 
С уважением,
Георгий Соколов
(программист)
[Нет ответов на это сообщение]
2002-12-18 16:00:23
Александр » Сергей В. Сычев

Добрый день, Сергей!

> Вопросы качества проекта для инженеров (не программистов) -

> это давно вопросы чести. Инженер -строитель после возведения

> моста по его проекту становится под мост и по мосту едет

> товарный поезд

Честно говоря, ни разу не слышал о таком в наши дни, а только читал в исторических книгах. Но допустим, что это так.

> а средне-статистический программист утверждает: "Техника

> сложна. Ошибки всегда будут. За работоспособность программы

> (мной же написанной) я отвечать не хочу".

За работоспособность программы в целом программист как раз отвечает. Если не своей честью, то как минимум своей зарплатой. Но только за работоспособность в целом - большую часть времени и/или в большинстве случаев.

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

Ближайшая аналогий - производство лекарств. Новые препараты тщательно тестируют, проверяют и перепроверяют по 3-5-7 лет (сравните со сроками тестирования средней программы!!!), и всё равно - из 100,000 человек, выпивших лекарство, на 99900 человек оно действует, как было запланировано, на 90 не действует вообще, а 10 попадают в больницу из-за побочных эффектов.

Кроме того, если сравнивать программирование с постройкой моста, представьте себе ситуацию, когда архитектор подготовил проект моста, началось строительство, но примерно на середине пришёл заказчик и сказал: "Знаете, голубчик - я говорил, что хочу мост на "быках", но я передумал. Сделайте его лучше подвесным. Но не начинайте проект сначала - так, переделайте тут и там, ведь это несложно, правда?" Спустя полгода заказчику захочется сделать уже подвешенный мост из двухполосного - шестиполосным. Но только чтобы не выводить его из эксплуатации больше чем на три часа. А ещё через три дня - укрепить его, чтобы по нему могли ездить танки и товарные поезда ("ну, заодно и рельсы проложите, делов то..."), и чтобы при этом мост сам собирал плату за проезд, фильтровал выхлопные газы и к тому же сам себя ремонтировал.

Не сомневаюсь, что архитектор в такой ситуации либо спустил заказчика ногами с лестницы, либо сошёл бы с ума, либо и то, и другое вместе. А вот любой программист наверняка припомнит пяток, если не десяток проектов, которые делались именно так. Инженерам-железячникам хорошо в том плане, что их заказчики понимают - нельзя переделать паровоз в пароход, можно только разобрать его на запчасти, что-то пустить в дело, что-то - в литьё, а потом собрать параход с нуля. А вот заказчик или менеджер программиста практически всегда пребывают в глубокой уверенности, что функциональность программы можно изменить на любом уровне вплоть до самого базового, переписав в ней пару строчек. Ну ладно, не пару - но уж за месяц-то всё можно сделать, правда? :(((

Ну и, наконец, добавлю, что архитектор не несёт ответственность за ситуации, когда его мост обрушился, скажем, из-за того, что в него врезался "Боинг" или его взорвали партизаны. Программистам же постоянно морочат голову тем, что его программа сбоит, даже если на самом деле сбоит операционная система, связь, железо или что-то ещё. Что делать - пользователь в момент аварии нажимал кнопку именно в этой программе.

В общем, лекарства тут не существует. Количество сбоев ПО можно уменьшить, если создание ПО будет проходить так, как строят, например, корабли или самолёты. Но даже в этом случае полностью избавиться от сбоев будет невозможно, как невозможно избавиться от аварий с теми же самолётами и кораблями.

> Простая фраза "Писать программы без брака" - сегодня могла

> бы стать миссией для любой софт-фирмы).

Если бы была выполнимой.

> И еще. Если лет 10 назад слово "программист" у большинства

> руководителей компаний вызывало стереотип "кого-то очень

> умного и непостижимого, творящего великие программные

> продукты", то сейчас все чаще и чаще стереотип "кого-то очень

> понятного, ленивого, вечно увольняющегося, не доделывающего

> проект, ворующего по мелкому комплектующие и получающего

> чаевые в компьютерных фирмах".

Таких просто не надо брать на работу. Радикальное такое лекарство :)

[Показать все ответы на это сообщение]
2002-12-18 18:32:24
Игорь Грешник » Александр

Уважаемый Александр!

>И если мост должен выполнять одну-единственную операцию стоять...

а) Данная функция сформулирована Вами неверно.

б) Мост выполняет несколько сотен функций.

в) Пароход (тем более, самолет) спроектировать и построить труднее, чем написать большую часть программ, написанных человечеством за последний год.

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

Вы в своем сообщении делаете ряд длинных выводов, основываясь на ошибочных тезисах (некоторые из них выше).

>Возникает такое количество комбинаций, которое человек просто не может охватить умом...

О том, что нельзя "объять необъятное" написал еще не-программист Козьма Прутков. Как раз, в попытке "охватить умом" и заключается одна из надсистемных ошибок, приводящая к ошибкам последующим... Эта ошибка носит название "нетехнологичная работа".

>Честно говоря, ни разу не слышал о таком в наши дни, а только

>читал в исторических книгах...

Отчего же. Могу познакомить. Кроме того, могу познакомить с врачами, делающими сегодня опыты на себе.

Вообще есть еще много чего такого о чем Вы не слышали.  Всех благ,

[Показать все ответы на это сообщение]
2002-12-18 18:51:44
Михаил Опанасенко » Александр

Александр!

Вы описали "аварийные взаимоотношения с Заказчиком", который меняет правила во время игры. Если такое происходит, то и ответственность ложится на такого Заказчика (или по крайней мере снимается с исполнителя). Однако, как мне кажется, это понимают участники обсуждения.

Но речь ведь идет о другом.

Я очень согласен с Сергеем Сычевым, который написал: "(...) имеем мин. две позиции:

а) "Вот есть сложная система и поэтому (серия примеров и аргументов) я ни за что не хочу ручаться"

     (Позиция 1)

б) "Да, эта система сложна, но я приложу максимум усилий, чтобы она работала стабильно. И в этом (кроме прочего) заключается моя профессиональная гордость".

     (Позиция 2)

Эти две позиции мы имеем и в данном обсуждении: есть коллеги, которые отстаивают Позицию 1. В частности, Ваша серия примеров и аргументов направлена на ее защиту.

А есть коллеги, которые защищают Позицию 2. Есть даже коллеги, которые не только защищают эту Позицию, но и разрабатывают методику "по сокращению ошибок" (например, Кирилл Лебедев). И кредит доверия к таким коллегам гораздо выше

>> Простая фраза "Писать программы без брака" - сегодня могла
>> бы стать миссией для любой софт-фирмы).

>Если бы была выполнимой

Мне кажется коллегам, которые поддерживают Позицию 2 полезно было бы подумать над работой, которую можно было бы назвать (условно): "Работа над ошибками". Можно ведь сколько угодно спорить о сложности мира, а можно решать задачи.

>Таких просто не надо брать на работу. Радикальное такое лекарство :)

Не надо менять тезис. Речь шла о том, что имидж профессии "программист" снижается. Это, к сожалению, имеет место быть.

С уважением,

[Показать все ответы на это сообщение]
2002-12-18 18:58:04
Редакция » Всем

Редакция присоединяется к позиции Георгия Соколова, а также благодарит Михаила Опанасенко за призыв к "Работе над ошибками".

С Уважением,

[Нет ответов на это сообщение]
2002-12-19 02:08:23
Рахманов Мартин » Всем

Применительно к России.

Присоединяюсь ко всему сказанному (почти), особенно к мыслям Vladimir Kirichenko. Только небольшая корректива - не Заказчик мало платит, а Руководство на "мало" соглашается. До тех пор, пока мы тут (Россия) за копье будем браться за все и вся, хорошего (в плане относительно малого числа ошибок) ПО нам не сделать. Да, есть единицы, которые будут подрывать здоровье за 1K в месяц и делать шедевры. Но индустрия не на единицах держится, а на массах. А массы работают за копейки по сравнению с Западом, что мы хотим... Не хочу сказать что все конторы так живут, но абсолютное большинство - именно так, "на коленке" любые проекты пишут, учатся на ходу тому-сему...

Подход должен быть другой - не брать работу за меньшие, чем у зарубежных коллег деньги. К персоналу относиться как к людям, а не к ресурсам. В общем, в корне все переделать. Понятное дело, что это нам уже не увидеть, т.ч. кто хочет нормально – нужно искать работу “там”.

[Нет ответов на это сообщение]
2002-12-19 14:00:59
Vladimir Kirichenko » Кирилл Лебедев
Есть и оборотная сторона медали.
Моя ответственность только за то, что находиться в области моего влияния. Как Вася может себя обвинять в том, что мост рухнул из-за слишком тяжелого поезда если:
1. Он не регулирует движением поездов.
2. Не вел рассчеты моста.
3. Вообще ничего не делал кроме ответсвенной работы замешивания бетона?

То же самое и в программировании. За архитектуру он не отвечает, железом не управляет на которой будет работать, зачастую слабо влияет на способ, объем и время реализации. Сказали deadline во вторник - что хочешь делай, а deadline во вторник. Часто реализует не так как думает правильно, но так как сказали сделать.

В таких условиях работы - это чистая блоготворительность со стороны Васи брать на себя какую-то там еще ответсвенность за фиксированнное вознаграждение.
[Показать все ответы на это сообщение]
2002-12-19 14:14:07
Vladimir Kirichenko » Игорь Грешник
> Многофакторность даже при производстве полиэтиленового пакета превышает на несколько порядков число комбинаций, которые нормальный технолог может удержать в голове.

Тогда так - если сравнисть скорость изменения и развития технологий при производстве полиэтиленового пакета(строительстве моста) и в программной сфере - где быстрее и на сколько порядков?

Архитектор моста может себе позволить спокойно поучиться в университете подороге читая интересные книги о новых сплавах и новых архитектурах, и выйти из университета обладая 90% знаний в своей области.

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

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

[Нет ответов на это сообщение]
2002-12-19 14:23:56
Vladimir Kirichenko » Михаил Опанасенко
=======================================
а) "Вот есть сложная система и поэтому (серия примеров и аргументов) я ни за что не хочу ручаться"
(Позиция 1)
б) "Да, эта система сложна, но я приложу максимум усилий, чтобы она работала стабильно. И в этом (кроме прочего) заключается моя профессиональная гордость".
(Позиция 2)
Эти две позиции мы имеем и в данном обсуждении: есть коллеги, которые отстаивают Позицию 1. В частности, Ваша серия примеров и аргументов направлена на ее защиту.
=======================================

Люди отстаивающие позицию 1 поступают в большинстве случаев честно(если не по простой лени). Потому что софт пишут побыстрому, задешево(а то и бесплатно).

Вот кусок из Apache license:

THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.

Люди писали софт бесплатно, если хотите пользоваться -пользуйтесь. Без гарантий. Люди писали софт задешево. По быстрому.

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

[Нет ответов на это сообщение]
2002-12-19 14:49:12
Александр » Михаил Опанасенко

> Вы описали "аварийные взаимоотношения с Заказчиком", который

> меняет правила во время игры.

В той или иной степени это происходит с каждым существенным проектом в области ПО.

>Я очень согласен с Сергеем Сычевым, который написал: "(...)

>имеем мин. две позиции:

>(Позиция 1)

>а) "Вот есть сложная система и поэтому (серия примеров и

>аргументов) я ни за что не хочу ручаться"

>(Позиция 2)

>б) "Да, эта система сложна, но я приложу максимум усилий, чтобы

>она работала стабильно. И в этом (кроме прочего) заключается

>моя профессиональная гордость"

Проблема в том, что второге не исключает первого. Да, разработчик приложил максимум усилий, да, его профессиональная гордость заключается в том, чтобы система работала "на ять" - но при этом он не может гарантировать, что программа не будет сбоить никогда, как разработчик лекарства не может гарантировать, что оно не повредит здоровью ни одного пациента. И тот, и другой может только назначить себе меру ответственности за каждый сбой.

Покажите мне хоть одну серьёзную программу, которая никогда не сбоит - и я встану на Вашу сторону. А до тех пор - увы.

>Не надо менять тезис. Речь шла о том, что имидж профессии

>"программист" снижается. Это, к сожалению, имеет место быть

А почему "к сожалению"? Совершенно нормальное явление. Сравните в этом плане профессию программиста с профессией шофера или летчика. Или даже с профессией космонавта. Гагарина знал весь мир. А кто там сегодня на орбите болтается, Вы помните?

Профессия существует всего несколько десятков лет. Когда-то она была элитной, программистов было мало, работа с компьютером требовала нетривиального склада ума, была доступна не каждому и потому таинственна и загадочна... А сегодня ситуация такова, что минимальными навыками программирования скоро будет владеть любой подросток.

Снижение имиджа в таких условиях предсказуемо и неизбежно. И вовсе не из-за качества работы.

[Нет ответов на это сообщение]
2002-12-19 16:12:33
Кирилл » Всем
Добрый день всем!
В качестве еще одной мысли по поводу системы обеспечения качества разрабатываемого под заказ ПО могу предложить подумать еще в таком направлении: если уж приводить примеры из области строительства, то надо приводить их полностью. Дело в том, что уважающий себя стройзаказчик (ну или компания, выполняющая функции управления строительными подрядами) имеет или должна иметь в своей структуре подразделение по обеспечению качества, которое контролирует в том числе качество выполненной проектной документации. Могу описать как это происходит, т.к. сам все это наблюдал воочию:
1. Компания-заказчик получает пакет рабочей документации (около 1000 листов чертежей, схем, узлов + сотни листов спецификаций)
2. В течении нескольких недель они рассматривают этот пакет.
3. Присылают список замечаний по пакету документации, в котором указаны: номер замечания, шифр и номер листа чертежа, категория замечания (критично/не критично), фамилия автора замечания/содержание замечания.
Т.е. определенный штат сотрудников методично смотрит каждый листок проекта (а их около 1000) и делает замечания каждый по своему разделу. Один специалист, например, просто читает номера ГОСТов и если они уже отменены или устарели, то пишет замечание.
Так вот собственно, что хотелось сказать: задача обеспечения качества ПО, писанного под заказ является (должна являться) ОБЩЕЙ для обеих сторон и для заказчика и для разработчика. И усилия и материальные средства должны с обеих сторон выделяться (представьте, сколько тратит строительная компания, платя в течении нескольких недель штату специалистов за проверку).
Да, забыл упомянуть одну деталь: счет на оплату услуг проектной организации утверждается только после устранения ВСЕХ замечаний из списка. Это сильный стимул подумать об обеспечении качества с самого начала на этапе разработки (список замечаний получется короче и счет утвердят быстрее).
[Нет ответов на это сообщение]
2002-12-23 01:00:44
Кирилл Лебедев » Vladimir Kirichenko
> Моя ответственность только за то, что находиться в области моего влияния.

Разумно. Но бывает, что области влияния программиста на программу хватает, чтобы исправить некоторые конструктивные недостатки. Поэтому часто полезно себя спрашивать: "Все ли я сделал для того, чтобы предотвратить этот недостаток?"

> Сказали deadline во вторник - что хочешь делай, а deadline во вторник. > Часто реализует не так как думает правильно, но так как сказали сделать.

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

> В таких условиях работы - это чистая блоготворительность со стороны Васи брать на себя какую-то там еще ответсвенность за фиксированнное вознаграждение.

Существует 2 подхода:
1. Дайте мне больше ресурсов (времени, денег), и я вам напишу качественную программу.
2. Я умею писать программы вот такого высокого качества. Если вас это заинтересует, то мне для работы нужны такие-то и такие-то ресурсы.

Второй подход, на мой взгляд, эффективнее, т.к. он не является голословным.

P.S. Для тех, кому интересно. Вышла новая статья по ошибкам в программах: http://www.homepc.ru/school/22854/
[Показать все ответы на это сообщение]
2002-12-23 13:34:20
Vladimir Kirichenko » Кирилл Лебедев
> Но я замечал, что наиболее качественные решения появляются именно тогда, когда соблюдается как первое, так и второе решения. Как говорится: "Необходимость обостряет разум".

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

> Существует 2 подхода:
> 1. Дайте мне больше ресурсов (времени, денег), и я вам напишу качественную программу.
> 2. Я умею писать программы вот такого высокого качества. Если вас это заинтересует, то мне для работы нужны такие-то и такие-то ресурсы.

> Второй подход, на мой взгляд, эффективнее, т.к. он не является голословным.

На что следует незамедлительный ответ, что это слишком дорого у меня нет столько времени,а в соседней конторе мне напишут дешевле и вовремя, почему вы думаете что вы такие уникальные? Я обращусь к соседу.

И не важно, что в плане качества и денег он не выиграет а может и вообще обламаться с проектом. Важно что колличество денег и времени величины неподконтрольные исполнителям и не бесконечные. А в условиях наличия большого колличества контор выигрывает тот кто предложит самое дешевое и быстрое решение. И если по счастливой случайности проект не загибается - клиенты начинают думать, что реалисты - это люди желающие их ограбить.
[Показать все ответы на это сообщение]
2002-12-25 00:37:04
Кирилл Лебедев » Виталий Онегов
> Дык получается, что я еще и должен искать какие-то другие недостатки за других людей?

Расширение зоны своей персональной ответственности - хороший прием для профессионального и карьерного роста.

> А может все же правильнее вот это высказывание: Спешка важно только при ловле блох ?

Согласно моей практике, спешка возникает не из-за через чур сильных ограничений по времени, а из-за нетехнологичности процесса разработки ПО.

> Так что с кем спорите по поводу надуманных подходов - хотя никто тут за первый не ратовал - я чего-то не пойму

К сожалению, уважаемые коллеги при обсуждении проблемы нехватки времени перекладывают ответственность на заказчика и вышестоящее начальство и не задаются вопросом: "Что неправильно в моих действиях, что мне приходится работать вечерами и по выходным?"
[Нет ответов на это сообщение]
2002-12-25 00:49:23
Кирилл Лебедев » Vladimir Kirichenko
> ... а так же продлевает рабочий день, плавно переходящий в рабочие выходные и рабочие ночи

Согласно моей практике такое происходит не из-за слишком сжатых сроков разработки ПО, а из-за нетехнологичности процесса разработки.
Например, при работе над последним проектом я потратил:
1) 10 - 15 % времени только из-за отсутствия должной коммуникации с одним из программистов "команды". Поскольку ни одна моя попытка не позволила установить с ним контакт, мне пришлось разбираться в его коде самому. Самому находить его баги. И предпринимать не всегда верные шаги. Он мог потратить час на объяснение. И ничего бы не потребовалось.
2) 20 - 30 % времени мне пришлось потратить на поиск нужной информации, ее изучение и отсев ненужной. В том числе - не только в Интернете, но и внутри компании. Если бы в фирме был организован информационный портал, в котором бы излагался и предыдущий опыт, мои затраты значительно бы сократились.
3) 20 - 30 % времени было потрачено из-за отсутствия технологии решения задач. Часто приходилось перебирать варианты, пытаться решить проблемы, которые не только не имели решения, но и которые-то решать не нужно было.

Итого: достаточно серьезные резервы для оптимизации по времени процесса разработки ПО.

> А в условиях наличия большого колличества контор выигрывает тот кто предложит самое дешевое и быстрое решение.

Проблема не в дешевизне проекта, а в нетехнологичности процесса получения заказа.
[Показать все ответы на это сообщение]
2002-12-25 10:14:06
Виталий Онегов » Кирилл Лебедев

>Согласно моей практике такое происходит не из-за слишком сжатых сроков разработки ПО, а из-за нетехнологичности процесса разработки.

 

Похоже на сказку про коммунизм: если бы все было хорошо, то жизнь была бы прекрасна.

Может кокурс объявим - кто найдет такого заказчика, который ну такой БЕЛЫЙ и ПУШИСТЫЙ, тому подарим приз :)))

И не надо все свешивать на нетехнологичность  - такую лапшу на уши можно начальству вешать. Тот, кто хоть раз участвовал в более-менее серьезном проекте, знает как все происходит и из-за чего переработки и все прочее. Об этом здесь и пишут. А если было бы так все просто - никто бы не перерабатывал - охота мне сидеть по выходным????

[Показать все ответы на это сообщение]
2002-12-25 10:22:47
Редакция » Виталий Онегов

Уважаемый Виталий! Ваше последнее сообщение содержит "код, абсолютно не обладающий никакой функциональностью".

Делаем Вам замечание за непродуктивность и некорректность.
[Нет ответов на это сообщение]
2002-12-25 13:16:20
Vladimir Kirichenko » Кирилл Лебедев
> Проблема не в дешевизне проекта, а в нетехнологичности процесса получения заказа.

:)))))
Класс:) Хочу технологический процесс получения заказов!

Требования к процессу:
- вменяемый клиент, способный изложить что он хочет.
- вменяемый клиент, способный понять, что процесс разработки ПО, не серийное производство одинаковых деталей и поэтому точно сказать завтра сколько займет/будет стоить то что он мне объяснил сегодня я не смогу.
- замороженые требования, либо вменяемость клиента в плане понимания, что любое изменения не вноситься парой строк кода, а оборачиваеться деньгами и временем.
- и последнее: клиент должен хотеть работающую программу, а не отчитаться перед своим начальником о том что "эти галимые программисты не выполнили простую работу в срок, а я ни в чем не виноват", в плане тогоб что клиент должет быть заинтересован в положительном результате, а не в политически выгодном для него.
[Показать все ответы на это сообщение]
2002-12-25 13:54:56
TBB » Кирилл Лебедев

Согласно моей практике такое происходит не из-за слишком сжатых сроков разработки ПО, а из-за нетехнологичности процесса разработки.
Например, при работе над последним проектом я потратил:
1) 10 - 15 % времени только из-за отсутствия должной коммуникации с одним из программистов "команды". Поскольку ни одна моя попытка не позволила установить с ним контакт, мне пришлось разбираться в его коде самому. Самому находить его баги. И предпринимать не всегда верные шаги. Он мог потратить час на объяснение. И ничего бы не потребовалось.

 

У нас, к примеру, все работают в тесном коллективе, друг до друга идти пешком меньше пары минут.


2) 20 - 30 % времени мне пришлось потратить на поиск нужной информации, ее изучение и отсев ненужной. В том числе - не только в Интернете, но и внутри компании. Если бы в фирме был организован информационный портал, в котором бы излагался и предыдущий опыт, мои затраты значительно бы сократились.

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

Может лучше обернуться на соседние фирмы, создающие (в отличии от вашей) библиотеки, DLL, и др. коды, предназначенные для повторного использования внутри (как минимум) той же фирмы.


3) 20 - 30 % времени было потрачено из-за отсутствия технологии решения задач. Часто приходилось перебирать варианты, пытаться решить проблемы, которые не только не имели решения, но и которые-то решать не нужно было.

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


Итого: достаточно серьезные резервы для оптимизации по времени процесса разработки ПО.

Итого: резерва не видно, есть только рекомендация перед тем как приступить к собственно программированию следует разобраться в ТЗ.

> А в условиях наличия большого колличества контор выигрывает тот кто предложит самое дешевое и быстрое решение.

Проблема не в дешевизне проекта, а в нетехнологичности процесса получения заказа.

Отчего же. "Дешевые" (в обсуждаемых здесь терминах) коллективы программистов перехватывают заказ (составляют смету) еще до построения ТЗ...

Такая вот диалектика.

;)

[Показать все ответы на это сообщение]
2002-12-25 14:21:54
Редакция » Всем

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

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

[Нет ответов на это сообщение]
2002-12-25 15:08:24
Георгий Соколов » Всем

Уважаемые коллеги!

1) Справедливость требует признать, что часто действительно, как Пишет Кирилл Лебедев "Проблема не в дешевизне проекта, а в нетехнологичности процесса...".

2) О том, как люди обваливают работу - рассказано здесь:                                        

 
3) Как люди САМооправдывают свои ошибки - рассказано в системе Help рабочей версии программы "Приемы журналистки & PR".

Успехов!

[Нет ответов на это сообщение]
2002-12-26 10:13:34
Кирилл » Михаил Опанасенко
Добрый день, Михаил!

Абсолютно согласен с замечанием:
>Не надо менять тезис. Речь шла о том, что имидж профессии "программист" снижается. Это, к сожалению, имеет место быть.

Весь сыр-бор (я имею ввиду вся дискуссия примерно с этого и началась, если кто-то помнит самое первое сообщение).
Одни участники убеждены, похоже, в том, что это связано лишь с низким _качеством_ разрабатываемого ПО и предлагают методы повышения качества и снижения количества ошибок, что само по себе на самом деле очень хорошо и все предлагаемые методы и информация полезны и важны.
Есть еще одно мнение, что иммидж падает, т.к. все созданные за последнее время программы слишком просты были в процессе создания по сравнению, например, с паровозом и тем не менее все же не были свободны от ошибок. Возможно так и есть.
Несмотря на безусловную важность всех этих моментов, считаю, что дело не только в этом. Возьмем маленько набивший аскомину пример с мостом: цель его создания и проектирования отнюдь не в том, чтобы продемонстрировать один раз трюк с товарным поездом, проезжающим над головой инженера. Если бы дело обстояло так, то иммидж профессии инженера-проектировщика мостов был бы схож с иммиджем циркового иллюзиониста. Но это не так, а объяснение в том, что мост соединяет 2 берега и по нему идет поток грузов, пассажиров и т.д. Это огромное значение для экономики и народного хозяйства :) региона, где этот мост построен. Так вот, если взять проектную документацию на этот мост, то я уверяю вас, что там стопудов есть и нестыковки всякие и ошибки и недостаточно продуманная система нумерации листов и перекрестных ссылок, которая усложняет работу подрядчика со всем ворохом бумаг и документов и он вынужден то и дело обращаться за разъяснениями к проектировщику. Я не говорю, что это на пользу иммиджу профессии инженера.
Но возьмем теперь софт-проект. Да, он уложился в сроки и бюджет, нет ни одного сбоя, работает при всех возможных конфигурациях, у заказчика нет ни единой претензии к его качеству. Сложность всей системы превышает сложность и многофакторность паровоза. Называтся проект "система 3-д скринсейверов". Я думаю, что иммидж останется там же, где и был.
Как все это относится к отношениям с заказчиком: я считаю, что самым важным является то, на сколько серьезные задачи удается решить создаваемым совместно проектом. И трудиться надо прежде всего над решением задач (творчески трудиться), чтобы оно было максимально эффективным, простым (кстати говоря, а не сложным, как паровоз), понятным, прозрачным и т.д. А частью функций по обеспечению качества проекта все же поделиться с заказчиком (это вполне общепринятая практика в том же строительстве, если уж говорить о других отраслях). Я скажу может кромольную вещь: если проект малобюджетный или share-ware, то частью функций по обеспечению качества поделиться даже с конечным пользователем может будет на пользу проекту.

С уважением, Кирилл.
[Показать все ответы на это сообщение]
2002-12-26 11:02:56
Михаил Опансенко » Кирилл

Уважаемый Кирилл! Вы пишите:

>я считаю, что самым важным является то, на сколько серьезные задачи удается решить >создаваемым совместно проектом. И трудиться надо прежде всего над решением задач >(творчески трудиться), чтобы оно было максимально эффективным, простым кстати >говоря, а не сложным, как паровоз), понятным, прозрачным и т.д. А частью функций по >обеспечению качества проекта все же поделиться с заказчиком (это вполне >общепринятая практика в том же строительстве, если уж говорить о других отраслях). >Я скажу может крамольную вещь: если проект малобюджетный или share-ware, то >частью функций по обеспечению качества поделиться даже с конечным пользователем >может будет на пользу проекту.

С этой точкой зрения я полностью согласен. Более того, как раз, явно показанное Заказчику желание решать сложные задачи, а проекты делать эффективными, простыми и прозрачными вырабатывает кредит доверия к разработчику. Если такой кредит доверия впоследствии оправдывается, то, собственно, имидж и начинает расти.

Когда же мы имеем обратную ситуацию, когда мы видим явный и заведомый отказ от желания решать сложные задачи и упрощать жизнь Клиенту, а не себе; когда мы видим поиск самооправдания этому отказу/неумению решить сложную задачу "через циклическую ссылку" на ее сложность; когда это нежелание выражено грубо и вина за собственную слабость перевешивается на Клиента (цитата: "Заказчик должен быть вменяемым и понимать что ему тут не ..."), то какой уж тут кредит доверия...

К сожалению, "обратных ситуаций" на рынке стало больше. Отсюда и соответствующие стереотипы Клиентов.

С другой стороны, может быть есть в этом и положительная сторона: у добросовестных разработчиков появится больше возможностей.

С уважением,

[Показать все ответы на это сообщение]
2002-12-26 16:32:19
Vladimir Kirichenko » Михаил Опансенко
=======================================
Когда же мы имеем обратную ситуацию, когда мы видим явный и заведомый отказ от желания решать сложные задачи и упрощать жизнь Клиенту, а не себе; когда мы видим поиск самооправдания этому отказу/неумению решить сложную задачу "через циклическую ссылку" на ее сложность; когда это нежелание выражено грубо и вина за собственную слабость перевешивается на Клиента (цитата: "Заказчик должен быть вменяемым и понимать что ему тут не ..."), то какой уж тут кредит доверия...
=======================================

А вы уверены что все заказчики готовы учавствовать в разработке? Имеют место случаи, когда заказчик приносит труд о трехстах страницах и говорит: вот вам требования, подготовленные моими аналитиками в течении 7 месяцев, мы выполнили за вас львиную долю работы - у вас есть 5 месяцев чтобы это реализовать, а меня не трогайте - всю имеющуюся информацию я вам предоставил.

Или фраза одного заказчика: "да я, когда учился в университете такое за пол часа делал....".

Так что вменяемость это критерий. Если ее нет....

[Показать все ответы на это сообщение]
2002-12-27 00:03:22
Кирилл Лебедев » Виталий Онегов
> Тот, кто хоть раз участвовал в более-менее серьезном проекте, знает как все происходит и из-за чего переработки и все прочее.

Я не знаю, почему случаются переработки у вас в фирме, но достаточно хорошо осведомлен о том, почему они происходят у нас. Причина: неправильная технология.
Пример 1. Новая версия игрового движка компилируется с новой версией игры за пару часов до времени отсылки версии заказчику. В результате выявляются баги, которые устраняют за остаток вечера и начало ночи. Результат: версия отсылается не в 7 вечера, а в 2 ночи.
Пример 2. Каждый из разработчиков под словом "сделал" понимает совершенно разное. Первый - просто сделал, но еще не объединил с изменениями коллег. Второй - сделал и объединил. Третий - сделал, объединил и проверил. Результат: доделка на скорую руку. Задержка отсылки версии.
[Нет ответов на это сообщение]
2002-12-27 00:10:11
Кирилл Лебедев » Vladimir Kirichenko
> Требования к процессу:
> - вменяемый клиент, способный изложить что он хочет.
> - вменяемый клиент, способный понять, что процесс разработки ПО, не > серийное производство одинаковых деталей и поэтому точно сказать
> завтра сколько займет/будет стоить то что он мне объяснил сегодня я > не смогу.

Вы излагаете требования к клиенту вместо того, чтобы излагать требования к себе и к технологическому процессу работы с заказчиком.
[Показать все ответы на это сообщение]
2002-12-27 16:02:23
Vladimir Kirichenko » Кирилл Лебедев
>Вы излагаете требования к клиенту вместо того, чтобы излагать требования к себе и к технологическому процессу работы с заказчиком.

Естественно:) Потому что работа над _совместным_ проектом эта работа _обоих_. Заказчик, когда ищет подрядчика, тоже имеет требования к подрядчику. И это не должно быть игрой в одни ворота. Если программисты должны стремиться делать все, чтобы проект был successful, заказчик тоже должен делать все. А на практике имеют место быть заказчики, которое предпочитают просмотреть утреннюю газету, не особо беспокоясь о том, как идет процесс чистки их ботинок программистами.
[Нет ответов на это сообщение]
2002-12-28 09:28:41
Кирилл » Vladimir Kirichenko
Добрый день!
По поводу вменяемости хочу сказать, что если (цитата): "... заказчик приносит труд о трехстах страницах и говорит: вот вам требования...", то это в бОльшей степени говорит как раз о вменяемости. То есть ребята твердо знают, чего они хотят. Но вот дальше "...у вас есть 5 месяцев чтобы это реализовать, а меня не трогайте - всю имеющуюся информацию я вам предоставил." Вот в этом и есть проблема - заказчик не видит в исполнителе своего партнера в деле реализации проекта. Но другие участники форума, как я понял, хотят сказать, что таких заказчиков большинство и при этом одним разработчикам удается-таки более или менее успешно работать в этой ситуации, а другие только без конца сетуют, что нормальных заказчиков нет.
То есть суть в том, что одним удается либо все таки выбить больше денег и ресурсов (времени и т.д.) из заказчика, либо потратить со своей стороны минимум усилий на реализацию. Секрет, на мой взгляд, в технологии получения заказа (напрасно тут иронизировали по поводу этого термина). Ну не нравится слово технология назовите "методы" или "способы" или "сценарии". Технология самое подходящее вобще-то, на мой взгляд, определение.
Вариант 1: заказчик говорит, что готов выделить на реализацию проекта определенную сумму, но есть основания предполагать, что эта сумма далеко не предел его возможностей.
Вопрос: как "выжать" больше денег (какие последовательные шаги для этого сделать)
Вариант 2: заказчик говорит, что готов выделить на реализацию проекта определенную сумму и это предел его возможностей (ясно, что выше ж...ы не прыгнешь)
Вопрос: как затратить со своей стороны адекватные этой фиксированной сумме усилия.
Понятно, что под "адекватностью усилий" недопустимо понимать низкое качество конечного продукта.
Понятно также, что заказы пусть даже с фиксированным и низким бюджетом на дороге не валяются. Если от них без конца отказываться в ожидании "вменяемого" заказчика, как в ожидании прекрасного принца, то можно так остаться не у дел.
Так вот вопрос такой есть: если кто-то может поделиться своим положительным опытом в вопросе технологии получения заказа, то это тоже было бы интересно всем, я думаю.
[Нет ответов на это сообщение]
2003-01-08 10:19:34
Силантьев Сергей » therapy.narod.ru
>> Ведь нужно говорить не о смертности, а о продолжительности жизни.

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

2. Безусловно хороший программист должен нести ответсвтенность за свой продукт, но в равной степени должен нести такую же ответсвенность и Поставновщик Задачи. Они ОБА должны нести ответственность. Как постановщик задачи объяснит цели и задачи будущего АРМ, так программист(хороший) и выполнит эту задачу и достигнет поставленной цели. Схема "Нужно написать то-то, но это должно работать ещё вчера и по нажатию одной кнопки, а если не напишешь, но не заплатим..." как раз и порождают кучу ошибок и проблем.

3. Самообразование. Поиск новых решений. Изучение новых технологий, в том числе и новых способов организации производственного процесса программистов. Мне кажется к этому должен стремиться хороший рограммист.

P.S. Эту дискуссию можно продолжать до опупения.
По поводу моста - бетономешальщик тоже несёт ответсвтенность за постройку моста. Если мост рухнет, то создаётся спецю комисиия по выяснению причины и на каком этапе. И тогда накажут всех, кого попало (и программистов тоже, как всегда)

P.P.S. Хочу лишь добавить, что почему то никто из (удалено Редакцией с предупреждением) не упомянул таких деталей:
- программист, прежде чем начать выполнять проект, ДОЛЖЕН изучить предметную область, которую он будет "программировать", но сам заказчик НЕ ДОЛЖЕН изучать языки программирования, технологии и др., с помощью которых будет реализовываться его задача.

Лично я, попутно, за 10 лет работы по специальности изучил технологический процесс создания пластиковых окон и дверей, процесс работы автозаправочных станций, бухгалтерский и товарный учёт и др... Сейчас вот изучай технологический процесс производства мороженного :))

3P.S. Программисты (настоящие) - народ плечистый. (удалено Редакцией со вторым предупреждением).
[Показать все ответы на это сообщение]
2003-01-08 10:55:15
Редакция » Силантьев Сергей

Уважаемый Сергей Силантьев!

На этом Форуме принято корректно общаться с коллегами.

[Показать все ответы на это сообщение]
2003-01-08 11:08:37
Силантьев Сергей » Редакция
Приношу свои извинения, если кто-то посчитал, что я пытался кого-то обидеть.

Может быть было немного эмоционально в конце...

Всех с Новым Годом! :))

[Нет ответов на это сообщение]
2003-08-04 13:18:01
Георгий Соколов » Всем
Уважаемые коллеги!
 
Думаю, Вам будет интересно.
 
Евг. Касперский рассказывает: "Многие мечтают работать в моей Лаборатории. Это, с одной стороны, легко, с другой — трудно. В общем-то наша Лаборатория — это нормальное предприятие западного типа. Очень строгое предприятие, уволить можем за любую мелочь. А как попасть? Вначале я просто беседую с человеком, смотрю, подходит ли он нам психологически, назначаю испытательный срок, смотрю на разработки. Большинство тех, кто к нам приходит, остается в Лаборатории на всю жизнь. Есть категория людей, которые никогда не будут работать у меня. Это повзрослевшие хакеры. В юности они делали вирусы, а я с ними боролся — в 30 лет они приходят ко мне заниматься антивирусными программами. Таких случаев было множество. Я отказывал. Не потому, что я держу на такого человека обиду (как полицейский держит обиду на футбольного хулигана). Просто у него хулиганское прошлое. Он слабый человек. Он может сойти с прямой дороги, уверенности в нем нет никакой..."
 
журнал "Мужская работа",  янв.-февраль 2003 г., с. 57.
[Нет ответов на это сообщение]


Яндекс.Метрика