Странник 6 Опубликовано: 9 мая 2010 Жалоба Рассказать Опубликовано: 9 мая 2010 Ситуация взята из жизни. Есть чётко сформулированное ТЗ и есть программист - подрядчик. Когда ставилась задача спросили его самого: -за месяц справишься? -справлюсь. Прошёл месяц, второй, третий разменяли... а программа так и болтается в виде сырого полуфабриката и не видать конца-края этой вроде бы отладке. Понятное дело, что в том конкретном случае имели место вполне объективные причины провала, но корень их всех сидел в классическом вопросе: как правильно назначить программисту срок сдачи готовой программы? P.S. Этот же вопрос задал другому программисту, а она в ответ говорит примерно таковы слова: начну программировать сегодня то, что должно быть готово завтра. Ссылка на сообщение Поделиться на других сайтах
SVB 188 Опубликовано: 9 мая 2010 Жалоба Рассказать Опубликовано: 9 мая 2010 Когда ставилась задача спросили его самого:Начинать надо было с выяснения того какие программы, в какие сроки и с каким интерфейсом и прочей икебаной делал ранее этот программист. Остальное — в разряде хотелок, про которые золотые слова сказал ещё В.С. Черномырдин. Ссылка на сообщение Поделиться на других сайтах
Странник 6 Опубликовано: 9 мая 2010 Автор Жалоба Рассказать Опубликовано: 9 мая 2010 Начинать надо было с выяснения того какие программы, в какие сроки и с каким интерфейсом и прочей икебаной делал ранее этот программист.Делал и похожие, и совсем не похожие, и простые, и сложные. Сроки тоже вроде как не срывал. Вопрос состоит в том, что надо как можно точнее спрогнозировать возможные объёмы дабы в рабочей неделе одного программиста не оказалось 170 часов, хотя бы он и пяткой в грудь себя со звоном ударял заявляя: начатых мною программ никому не передам! Ссылка на сообщение Поделиться на других сайтах
a_schelyaev 366 Опубликовано: 9 мая 2010 Жалоба Рассказать Опубликовано: 9 мая 2010 Чем более подробно написано ТЗ, тем меньше разработчику придется думать и тем больше ему придется заниматься именно написанием кода и его отладкой. Соответственно, чем более опытный разработчик, тем он сам более способен оценить трудозатраты. Поэтому, после получения ТЗ, он должен составить план работ. Ты должен вникнуть в план и в то, что он хочет сделать. Если кодер очень старательный и страдает перфекционизмом, то нужно кастрировать его план, чтобы в первую очередь реализовывались самые основные вещи, а лоск будет наводить потом. Еще очень важный момент, расставить даты и временные интервалы, когда он будет работать только по твоей теме, и когда будут завершены каждый из пунктов плана. По мере прохождения контрольных этапов тебе станет ясно - успевает он или нет. Если нет, то копай причины - раздолбай; слишком загружен; не компетентен. НАйдя причину разбирайся с ней - пугай; предлагай премию; ищи другого. К сожалению, в данном ремесле все очень сильно зависит от человека. Ты можешь рисовать сколь угодно продвинутые планы в своей голове, но все они разобьются об него, если он балбес. Ссылка на сообщение Поделиться на других сайтах
Странник 6 Опубликовано: 9 мая 2010 Автор Жалоба Рассказать Опубликовано: 9 мая 2010 Чем более подробно написано ТЗ, тем меньше разработчику придется думать и тем больше ему придется заниматься именно написанием кода и его отладкой. Соответственно, чем более опытный разработчик, тем он сам более способен оценить трудозатраты. Иначе сказать, для этого непременно нужно и самому быть классным программистом? Тут сидит засада - программист не знает специфики поля применения создавемой программы, а постановщик задачи не настолько искушён в тонкостях программирования, чтобы профессиональный программёр не возмог водить его за нос, при желании. ИМХО, в рассматриваемом примере ТЗ было написано достаточно подробно, вплоть до пошагового раскрытия каждой процедуры и ожидаемого вида интерфейса... но этого оказалось недостаточно. Поэтому, после получения ТЗ, он должен составить план работ. Ты должен вникнуть в план и в то, что он хочет сделать. Если кодер очень старательный и страдает перфекционизмом, то нужно кастрировать его план, чтобы в первую очередь реализовывались самые основные вещи, а лоск будет наводить потом. Еще очень важный момент, расставить даты и временные интервалы, когда он будет работать только по твоей теме, и когда будут завершены каждый из пунктов плана. По мере прохождения контрольных этапов тебе станет ясно - успевает он или нет. Если нет, то копай причины - раздолбай; слишком загружен; не компетентен. НАйдя причину разбирайся с ней - пугай; предлагай премию; ищи другого. Изначально и была выделн некий набор упрощенных базовых процедур и даже одна самая ходовая из них, но только на уровне алгоритма, без привязки к возможным 13 if (A<N) go to 14 14 DO 15 (i=1,1000000000) 15 CALL SABOTASHE STOP END С проектированием железок проще, обладая некоторой статистикой можно спрогнозировать приблизительный объём КД в листах формата А4 и поставить обоснованные сроки исходя из наличия да квалификации кадров. По мере продвижения документации по инстанции можно отследить какие именно звенья вызывают наибольшее торможение и изменения от начального варианта (например: "т.контр." нагло пытается внести в КД технологические требования, либо "пров."/"н.контр." добивается переупорядочивания видов/позиций в угоду собственному эстетическому чуйству). С CAD-моделями уже сложнее, а ведь это тоже своего рода язык программирования! Иногда поражаешься как легко и просто опытный конструктор с большими навыками работы в системе решает задачи, о которые сломало все свои вумные головы не одно, и даже не два предприятия. Однако такого парня не посадишь проверять ВСЕ модели завода или КБ, разве что пусть он сформулирует принципы и алгоритмы оценки качества, а профессиональные программисты реализуют плагинчик. Но какие могут быть применены критерии для определения обоснованности срока выпуска программы на языке высокого уровня? Ссылка на сообщение Поделиться на других сайтах
a_schelyaev 366 Опубликовано: 9 мая 2010 Жалоба Рассказать Опубликовано: 9 мая 2010 Иначе сказать, для этого непременно нужно и самому быть классным программистом? Нет. Тут сидит засада - программист не знает специфики поля применения создавемой программы, а постановщик задачи не настолько искушён в тонкостях программирования, чтобы профессиональный программёр не возмог водить его за нос, при желании. Это нормальная ситуация, не парься. Поэтому ты должен обставить процесс так, чтобы он был тебе понятен, в первую очередь. ПОэтому и важно расписать блок-схему основных модулей программы на уровне ее структуры, рабочую цепочку движения информации, протоколы обмена и прочее. Чтобы это сделать не нужно знать программирование, нужно знать Ворд и просто логически мыслить. Именно эти вещи и должны быть заложены в ТЗ. Именно твою логику процесса и будет реализовывать кодер. РАсписать интерфейс очень важно, т.к. это может сильно повлиять на код и его устройство. Почему важно структуру описать и обмен данными внутри этой структуры? Потому что тогда каждый такой кусок кода можно будет писать и отдавать на тестирование. Повторюсь: свою структуру тебе нужно разложить в последовательность - что реализовывать в первую очередь, что реализовывать потом. На каком этапе можно будет проверить функциональность. Например, чтобы проверить логику некоторых веток алгоритма не обязательно иметь сразу графический интерфейс тот что в ТЗ прописан. Как только ты в своей голове разложил код по блоками и ты знаешь что должно пойти на вход, а что на выход, то можно это уже щупать ручками. Ну а также ты видишь реально степень готовности твоего будущего приложения. Потом начнете по кускам сшивать блоки и тестировать уже в комплексе. ИМХО, в рассматриваемом примере ТЗ было написано достаточно подробно, вплоть до пошагового раскрытия каждой процедуры и ожидаемого вида интерфейса... но этого оказалось недостаточно. Если, как ты утверждаешь, ТЗ было полным, а оно все равно никак, то значит проблема в человеке. Видимо он отдает свое время чему-то еще. МОжет быть халтуре. Но какие могут быть применены критерии для определения обоснованности срока выпуска программы на языке высокого уровня? ПРограмма должна работать. А если формально: 1. Выполненная работа должна соответствовать ТЗ. 2. Должен быть пройден набор тестов - автоматическая система тестирования или сам сидишь и как папа Карло тычешь в экран отрабатывая все возможные комбинации. 3. Программа должна быть протестирована заказчиком, составлен акт недоработок. Ссылка на сообщение Поделиться на других сайтах
Странник 6 Опубликовано: 10 мая 2010 Автор Жалоба Рассказать Опубликовано: 10 мая 2010 Это нормальная ситуация, не парься. Поэтому ты должен обставить процесс так, чтобы он был тебе понятен, в первую очередь. ПОэтому и важно расписать блок-схему основных модулей программы на уровне ее структуры, рабочую цепочку движения информации, протоколы обмена и прочее. В проектировании железяк это выглядит так: функциональная схема -> общая компоновка -> электрическая принципиальная схема.При этом у хорошего проектанта получается именно набор функционально законченных агрегатов/блоков/отсеков с чётко оговоренными посадочными да стыковочными местами. С такими принципами построения железка всегда получается качественной и в производстве, и в эксплуатации. Иногда это называют модульной конструкцией с высокой инновационной способностью, но есть нюанс - таковое никогда не ндравится менегменту, бо сразу дурь каждого становится видна. Почему важно структуру описать и обмен данными внутри этой структуры? Потому что тогда каждый такой кусок кода можно будет писать и отдавать на тестирование. Повторюсь: свою структуру тебе нужно разложить в последовательность - что реализовывать в первую очередь, что реализовывать потом. На каком этапе можно будет проверить функциональность. Совершенно верно, в производстве изделий работают теже принципы и чем грамотнее общее разложено на сборки - подсборки тем меньше получается всякого рода "броуновского движения" на всех этапах ЖЦИ. Однако "подводный камень" есть и тут: -теоретику нужно во что бы то ни стало подтвердить преимущество своего решения над оптимальным; -технологу хочется чтобы КД была настолько сильно адаптированна к конкретному производству, чтоб даже не требовалось писать техпроцесс; -снабженцу/комплектаторщику надо чтобы всё делалось ни из чего иного, как из того что уже имеется на складе; -схемотехник... тому зачастую вообще что бы ни делать, только бы ничего не делать- и т.п. В общем: коси и забивай!Бороться с этим вредительством со стороны служб предприятия может и должен (!) менегер, но уровень его компетентности в технических вопросах, как правило, находится ниже плинтуса, а посему и вся эта братия очень легко обводит его вокруг пальца + делится уворованным. В связке постановщик - кодер очевидно должны будут иметь место подобные же казусы. Например: программисту нравится FORTRAN, а оптимальным языком для этой задачи являлся бы С++, то бишь в программе получится 1500 строчек вместо потребной 1000, со всеми отсюда вытекающими проблемами при отладке и в количестве пользовательских диалогов. Но как не будучи классным программистом отловить сие безобразие на раннем этапе? Если, как ты утверждаешь, ТЗ было полным, а оно все равно никак, то значит проблема в человеке. Видимо он отдает свое время чему-то еще. МОжет быть халтуре.Видимо по ходу дела так оно и было, только врядли можно вести речь о халтуре. Скорее всего опять всё упёрлось в управление, так сказать классическое: спячка -> раскачка -> горячка -> наказание невиновных -> награждение непричастных 1. Выполненная работа должна соответствовать ТЗ. 2. Должен быть пройден набор тестов - автоматическая система тестирования или сам сидишь и как папа Карло тычешь в экран отрабатывая все возможные комбинации. 3. Программа должна быть протестирована заказчиком, составлен акт недоработок. Хм... действительно, работать на доверительном уровне ныне уже нельзя. Приму к сведению. Спасибо. Ссылка на сообщение Поделиться на других сайтах
a_schelyaev 366 Опубликовано: 10 мая 2010 Жалоба Рассказать Опубликовано: 10 мая 2010 В проектировании железяк это выглядит так: Это монопенисуально во всех отраслях, где идет разработка силами белых и прочих обезьян: абстракция декомпозиция итерация или говоря по китайски - разделяй и властвуй. Бороться с этим вредительством со стороны служб предприятия может и должен (!) менегер, но уровень его компетентности в технических вопросах, как правило, находится ниже плинтуса, а посему и вся эта братия очень легко обводит его вокруг пальца + делится уворованным. Тут все довольно таки банально. Составляется структура работы вашего организма - предприятия, процесса разработки или чего угодно. На входе ты имеешь материалы, время и деньги, а на выходе трату материалов, времени, денег и получаемое качество на единицу продукции. Потом начинаешь изыскивать меры по снижению издержек на всех этапах. МОжно начать с понятных тебе этапов. Если твои кренделя не способны придумать ничего в силу корумпированности или некомпетентности, то либо нанимаешь к себе в помощь новичка после ВУЗа, с горящими глазами и он еще не будучи задействованным в гнилой системе начинает рыть землю руками. Или привлекаешь внешних аудиторов. В связке постановщик - кодер очевидно должны будут иметь место подобные же казусы. Например: программисту нравится FORTRAN, а оптимальным языком для этой задачи являлся бы С++, то бишь в программе получится 1500 строчек вместо потребной 1000, со всеми отсюда вытекающими проблемами при отладке и в количестве пользовательских диалогов. Но как не будучи классным программистом отловить сие безобразие на раннем этапе? Это все фигня. C++ не самоцель и ФОРТРАН тоже нормальный язык. Это все критично, если тебе придется передавать код другому разработчику или привлекать дополнительных кодеров. Вот тут может встать вопрос совместимости и денег. Написать прожку в Дельфи или VisualC или VisualBasic будет стоить разных денег и поиск кодера может занять больше времени. Если приводить аналогию, то по большому счету SolidWOrks и Inventor близнецы братья. Критично в этой ситуации как ты будешь работать со смежниками, т.е. вопрос совместимости данных. Хм... действительно, работать на доверительном уровне ныне уже нельзя. Приму к сведению. Спасибо. Не за что. Помни, что именно по этой причине и появились вские PLM за(мо/д)рочки - начальник хочет чтобы его владения были для него понятны. ЧТобы было понятно кто что делает и куда бабки уходят и время. Старайся вникать во все сам по мере возможностей. Там гед тебе уже непонятно выдвигай такие контрольные критерии, чтобы было все ясно. Ссылка на сообщение Поделиться на других сайтах
Странник 6 Опубликовано: 14 мая 2010 Автор Жалоба Рассказать Опубликовано: 14 мая 2010 Помни, что именно по этой причине и появились вские PLM за(мо/д)рочки - начальник хочет чтобы его владения были для него понятны. ЧТобы было понятно кто что делает и куда бабки уходят и время. Хм, весьма полезный постулат, жаль только его не часто озвучивают в литературе и тырнете, наипаче же скромничают продавцы Workflow и PDM и именно перед менегментом. Старайся вникать во все сам по мере возможностей. Там гед тебе уже непонятно выдвигай такие контрольные критерии, чтобы было все ясно. В следующий раз так и наверно поступлю, а в данном конкретном примере похоже уже всё ясно. Интересно, что по среднестатистическим подходам следует делать с личностями, которые совсем некомпетентны в теме создаваемой программы и даже не отдают себе отчёта в тяжести последствий провала, но имеют полулегальную возможность подгружать кодера другими работами? А с кодером, что так охотно ведётся на эти штучки? Ссылка на сообщение Поделиться на других сайтах
Странник 6 Опубликовано: 11 августа 2010 Автор Жалоба Рассказать Опубликовано: 11 августа 2010 <noindex>Может кому будет интересно.</noindex> Ссылка на сообщение Поделиться на других сайтах
Рекомендованные сообщения