Срок готовности программы

[Странник 6]

Ситуация взята из жизни.

Есть чётко сформулированное ТЗ и есть программист - подрядчик.

Когда ставилась задача спросили его самого:

-за месяц справишься?

-справлюсь.

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

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

P.S. Этот же вопрос задал другому программисту, а она в ответ говорит примерно таковы слова:

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

[SVB 188]

Когда ставилась задача спросили его самого:

Начинать надо было с выяснения того какие программы, в какие сроки и с каким интерфейсом и прочей икебаной делал ранее этот программист. Остальное — в разряде хотелок, про которые золотые слова сказал ещё В.С. Черномырдин.

[Странник 6]

Начинать надо было с выяснения того какие программы, в какие сроки и с каким интерфейсом и прочей икебаной делал ранее этот программист.

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

начатых мною программ никому не передам!

[a_schelyaev 371]

Чем более подробно написано ТЗ, тем меньше разработчику придется думать и тем больше ему придется заниматься именно написанием кода и его отладкой.

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

Поэтому, после получения ТЗ, он должен составить план работ.

Ты должен вникнуть в план и в то, что он хочет сделать.

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

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

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

НАйдя причину разбирайся с ней - пугай; предлагай премию; ищи другого.

К сожалению, в данном ремесле все очень сильно зависит от человека.

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

[Странник 6]

Чем более подробно написано ТЗ, тем меньше разработчику придется думать и тем больше ему придется заниматься именно написанием кода и его отладкой.

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

Иначе сказать, для этого непременно нужно и самому быть классным программистом?

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

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

Поэтому, после получения ТЗ, он должен составить план работ.

Ты должен вникнуть в план и в то, что он хочет сделать.

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

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

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

НАйдя причину разбирайся с ней - пугай; предлагай премию; ищи другого.

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

13 if (A<N) go to 14

14 DO 15 (i=1,1000000000)

15 CALL SABOTASHE

STOP

END

С проектированием железок проще, обладая некоторой статистикой можно спрогнозировать приблизительный объём КД в листах формата А4 и поставить обоснованные сроки исходя из наличия да квалификации кадров.

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

С CAD-моделями уже сложнее, а ведь это тоже своего рода язык программирования! Иногда поражаешься как легко и просто опытный конструктор с большими навыками работы в системе решает задачи, о которые сломало все свои вумные головы не одно, и даже не два предприятия. Однако такого парня не посадишь проверять ВСЕ модели завода или КБ, разве что пусть он сформулирует принципы и алгоритмы оценки качества, а профессиональные программисты реализуют плагинчик.

Но какие могут быть применены критерии для определения обоснованности срока выпуска программы на языке высокого уровня?

[a_schelyaev 371]

Иначе сказать, для этого непременно нужно и самому быть классным программистом?

Нет.

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

Это нормальная ситуация, не парься. Поэтому ты должен обставить процесс так, чтобы он был тебе понятен, в первую очередь.

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

Именно твою логику процесса и будет реализовывать кодер.

РАсписать интерфейс очень важно, т.к. это может сильно повлиять на код и его устройство.

Почему важно структуру описать и обмен данными внутри этой структуры? Потому что тогда каждый такой кусок кода можно будет писать и отдавать на тестирование.

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

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

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

Если, как ты утверждаешь, ТЗ было полным, а оно все равно никак, то значит проблема в человеке. Видимо он отдает свое время чему-то еще. МОжет быть халтуре.

Но какие могут быть применены критерии для определения обоснованности срока выпуска программы на языке высокого уровня?

ПРограмма должна работать. А если формально:

1. Выполненная работа должна соответствовать ТЗ.

2. Должен быть пройден набор тестов - автоматическая система тестирования или сам сидишь и как папа Карло тычешь в экран отрабатывая все возможные комбинации.

3. Программа должна быть протестирована заказчиком, составлен акт недоработок.

[Странник 6]

Это нормальная ситуация, не парься. Поэтому ты должен обставить процесс так, чтобы он был тебе понятен, в первую очередь.

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

В проектировании железяк это выглядит так:

функциональная схема -> общая компоновка -> электрическая принципиальная схема.

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

дурь каждого становится видна.

Почему важно структуру описать и обмен данными внутри этой структуры? Потому что тогда каждый такой кусок кода можно будет писать и отдавать на тестирование.

Повторюсь: свою структуру тебе нужно разложить в последовательность - что реализовывать в первую очередь, что реализовывать потом. На каком этапе можно будет проверить функциональность.

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

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

-технологу хочется чтобы КД была настолько сильно адаптированна к конкретному производству, чтоб даже не требовалось писать техпроцесс;

-снабженцу/комплектаторщику надо чтобы всё делалось ни из чего иного, как из того что уже имеется на складе;

-схемотехник... тому зачастую вообще

что бы ни делать, только бы ничего не делать

- и т.п.

В общем:

коси и забивай!

Бороться с этим вредительством со стороны служб предприятия может и должен (!) менегер, но уровень его компетентности в технических вопросах, как правило, находится ниже плинтуса, а посему и вся эта братия очень легко обводит его вокруг пальца + делится уворованным.

В связке постановщик - кодер очевидно должны будут иметь место подобные же казусы. Например: программисту нравится FORTRAN, а оптимальным языком для этой задачи являлся бы С++, то бишь в программе получится 1500 строчек вместо потребной 1000, со всеми отсюда вытекающими проблемами при отладке и в количестве пользовательских диалогов. Но как не будучи классным программистом отловить сие безобразие на раннем этапе?

Если, как ты утверждаешь, ТЗ было полным, а оно все равно никак, то значит проблема в человеке. Видимо он отдает свое время чему-то еще. МОжет быть халтуре.

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

спячка -> раскачка -> горячка -> наказание невиновных -> награждение непричастных

1. Выполненная работа должна соответствовать ТЗ.

2. Должен быть пройден набор тестов - автоматическая система тестирования или сам сидишь и как папа Карло тычешь в экран отрабатывая все возможные комбинации.

3. Программа должна быть протестирована заказчиком, составлен акт недоработок.

Хм... действительно, работать на доверительном уровне ныне уже нельзя. Приму к сведению.

Спасибо.

[a_schelyaev 371]

В проектировании железяк это выглядит так:

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

абстракция

декомпозиция

итерация

или говоря по китайски - разделяй и властвуй.

Бороться с этим вредительством со стороны служб предприятия может и должен (!) менегер, но уровень его компетентности в технических вопросах, как правило, находится ниже плинтуса, а посему и вся эта братия очень легко обводит его вокруг пальца + делится уворованным.

Тут все довольно таки банально.

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

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

Потом начинаешь изыскивать меры по снижению издержек на всех этапах. МОжно начать с понятных тебе этапов.

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

Или привлекаешь внешних аудиторов.

В связке постановщик - кодер очевидно должны будут иметь место подобные же казусы. Например: программисту нравится FORTRAN, а оптимальным языком для этой задачи являлся бы С++, то бишь в программе получится 1500 строчек вместо потребной 1000, со всеми отсюда вытекающими проблемами при отладке и в количестве пользовательских диалогов. Но как не будучи классным программистом отловить сие безобразие на раннем этапе?

Это все фигня. C++ не самоцель и ФОРТРАН тоже нормальный язык.

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

Написать прожку в Дельфи или VisualC или VisualBasic будет стоить разных денег и поиск кодера может занять больше времени.

Если приводить аналогию, то по большому счету SolidWOrks и Inventor близнецы братья.

Критично в этой ситуации как ты будешь работать со смежниками, т.е. вопрос совместимости данных.

Хм... действительно, работать на доверительном уровне ныне уже нельзя. Приму к сведению.

Спасибо.

Не за что.

Помни, что именно по этой причине и появились вские PLM за(мо/д)рочки - начальник хочет чтобы его владения были для него понятны.

ЧТобы было понятно кто что делает и куда бабки уходят и время.

Старайся вникать во все сам по мере возможностей.

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

[Странник 6]

Помни, что именно по этой причине и появились вские PLM за(мо/д)рочки - начальник хочет чтобы его владения были для него понятны.

ЧТобы было понятно кто что делает и куда бабки уходят и время.

Хм, весьма полезный постулат, жаль только его не часто озвучивают в литературе и тырнете, наипаче же скромничают продавцы Workflow и PDM и именно перед менегментом.

Старайся вникать во все сам по мере возможностей.

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

В следующий раз так и наверно поступлю, а в данном конкретном примере похоже уже всё ясно.

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

[Странник 6]

<noindex>Может кому будет интересно.</noindex>