Не само програмисти

Ще се опитам да изложа малко идеи, дано успеете да различите мнението и въпросите ми, аз все още разсъждавам по тази тема и ми е малко каша в главата.

Става въпрос за:

- Програмисти, които са професионалисти (или поне имат добри познания) и в друга област, както и до колко ценни, ценени, търсени и откриваеми са те. В моите очи такива хора са огромен плюс, когато се работи по проект в тяхната "друга" специалност. bira_more, моля те, ако прочетеш това, сподели опита си!

- Комуникацията между програмистите, като изпълнители, и тесните специалисти, като задаващи изискванията за софтуера и ползващи го в последствие. Приемам ги като две крайни позиции и въпросът ми е: къде е редно, или къде е най-удобно, да бъде свързващият елемент? Говоря за специализиран софт! Пример - счетоводен софтуер, експертна система... Трябва ли програмистът да разбира от счетоводство?? Или счетоводителя да знае нещо за програмирането, за да може да обясни какво му трябва с разбираеми за програмиста понятия? Има ли място за посредник, който не е гуру в нито една от тези 2 сфери, но може да организира КОМУНИКАЦИЯТА?

- Как става номерът с планирането на цялата система? Какво се прави ПРЕДИ да се седне да се пише?

Проблеми с програмирането мога да реша и с хелпове и Гугъл. В този случай ви моля да споделите мнения и опит от друго естество. За мен те са важни.

Счетоводителя трябва да разбира от системен анализ и да ти нахвърля няколко ... UML диаграми с помощта на програмиста...

Щом е счетоводител би трябвало да има ако не такива познания, то настройка за подобен вид "мислене"...

И горе долу ... XP му е майката и таткото...

90% е въпрос на добър проект. Проектирането на софтуер обаче е отделна наука, чиито аспекти са трудно отразими в един пост. Плюс това съществуват толкова системи и модели за проектиране, че може свят да ти се завие...

"Има ли място за посредник, който не е гуру в нито една от тези 2 сфери, но може да организира КОМУНИКАЦИЯТА"

Този не е ли точно мениджъра?

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

Иначе такава длъжност има - бизнес аналитик / системен аналитик... ей такива едни думички

Сигнатура!

Може?
Звучи логично.
Да си призная честно, не знам докъде се простират задълженията на мениджъра. Нито точно откъде започват.

Проклятие! Да разбирам ли, че пак трябва да чета, ако това ми е интересно?
Някакви насоки, все пак?

ОК, явно без книги няма да се мине...
А все пак, някакви твои ЛИЧНИ впечатления? Зарежи теорията, ще си я гледам (в някой момент, може би...), можеш ли да споделиш нещо от практиката? Не търся обосновани теории, а мнения на хора, които работят и имат опит с такива неща.

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

Лично впечатление - във всякя фирма имат различна представа какво означават тия думички, и съответно и 'длъжността' на този, който се занимава с клиента се казва по различен начин.

Като почнеш от аналитици, project managers, product managers...шефа, самите програмисти .

Както се сещаш, с великото ни образование и великите проекти, които се правят в hi-tech страната ни, е бъкано с професионалисти във всички тези области

( Работили съм само в една фирма със системн и др. аналитици, но там нещата се бяха изродили в произвеждане на никому ненужна документация )

Сигнатура!

Грубо казано, реализирането на един голям или със специфична тематика софтуерен проект включва:
1) проектиране
2) изпълнение
3) поддръжка
И за трите фази има тонове съвети и литература, така че най-удачния вариант е да се закачиш за готова изпробвана система и да я адаптираш за наличните ресурси.
Пример:
1) проектиране - аз ползвам трислоен модел за проекта:
- логически - описание на целите, които трябва да може да се постигнат със софтуерния продукт
- физически - описание на апаратните средства, технологии и прочее с които ще се постигне логическия модел
- функционален - описание на функционалноста - заявка от потребителя и съответната реакция на продукта
2) изпълнението - на базата на готовия и съгласуван с клиента проект се изготвя задание. Заданието е всъщност разпределение на ресурсите:
- задачи
- време
- изпълнители
Това разпределение включва изграждането на продукта, например за типичното web приложение:
- база данни
- dataflow при сървъра
- темплейти
- dataflow при клиента
3) поддръжка
- гореща поддръжка и поправки
- evaluation error tracking (писна ми да превеждам )
- документиране, литература, примери и прочее

Това е само примерен модел, той работи доста добре при нас. При друга фирма и организация резултатите естествено са различни. Освен това се гледа какъв е кефа на шефа, какво е чел и/или си спомня най-якия девелопер в групата и ред други "обективни" фактори, способни да изменят или изкилифищят и най-добрата система

в твоя случай незнам ама знам как сега си блъскам главата над 2-3 програми без каквато и да е документация, щото преди никой не е писал нищо и колегата като отиде войник и познайте кой сега си губи времето за разчитане на код и алгоритми

Радвай се, щото иначе документацията можеше да е грешна и/или outdated

Сигнатура!

В един сайт се бях определил като най-добрия програмист сред лекарите и най-добрия лекар сред програмистите - ни лекар ни програмист.
Имам 2 типични примера и си мисля че те сами по себе си са достатъчно показателни:
На времето направихме телемедицинска система. Система която поддържаше всичко което може да се вкара в една История на Заболяването, да изпрати информацията до отдалечен сървър, съответно информацията да бъде изтеглена от лекар специалист, и съответно по обратния ред да се върнат мнения, препоръки и т.н.
Системата бял свят не видя - беше докарана до бета стадий, но дойде Аремис-софт, ЗОК и т.н. и мисля че няма смисъл да разказвам на татък.

Имам и няколко разработки - за оценка вариабилност на сърдечна честота, и оценка на методи за оценка на ВСЧ. Справих се само благодарение на програмирането. В смисъл - правиш програма която ти позволява да разбереш някои неща, модифицираш програмата в съответствие с новите открития и т.н.

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

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

Фактически ако тръгнеш да правиш счетоводен софтуер, щеш нещеш ще научиш доста неща за счетоводството. Ако тръгнеш да правиш медицински софтуер - ще научиш доста неща за медицината. Познавам инжинери, които наистина могат да разчитат ЕКГта по добре от доста лекари :)))))

Bеer? Mоre?
Плацебото

Познавайки медицината и програмирането, мога да се сетя за неща които биха били полезни за един лекар - няма да чакам на всяка крачка за задание. От друга страна знам какво може да се направи (с един компютър) в сравнение с лекар непрограмист. - по този повод:

Това може би е един от най-съществените плюсове на хора, които не са "чисти програмисти" (хехе, мръсници!*).
Защото едно е да ти поръчат програмка, която да прави това и това, друго е ти да се присетиш да направиш продукт, който в последствие да предложиш и продадеш. В първия случай ти подават идея, във втория идеята е твоя.
Клиентът знае какво иска (в идеалния случай), програмистът знае какво може да се направи. А хора, които гледат и от двете позиции**, са на изключително стратегическо място. Ако съумеят да се възползват от това си положение (или ако някой съумее да се възползва от това им положение), могат да станат доста интересни неща.

*не ми обръщайте внимание, обичам да се отплесвам.
**...стават разногледи

най-грубо процеса (в мойта фирма - скоро бивша) е следния.

1. събиране на изисквания (requirements gathering) - определен човек (специалист) отива при клиента и дискутира, какво се иска да се направи.

2. изготвяне на спецификация - след като е определил, какво се иска, съответния служител (мениджър в нашия случай), изготвя спецификация, в която описва, какво точно е разбрал. след този етап, обикновено може да се говори и за някаква цена.

3. ако спецификацията се одобри (клиента смята, че неговите изисквания са покрити) и цената е приемлива за двете страни се преминава към изработката.

има и други модели (XSP, ASD), но аз лично смятам този за по-добър

El rito constituye el Secreto

Хехе, най-якия девелопер в групата определено е много интересен фактор!
Благодаря за изчерпателния отговор!
И само още нещо мъничко... до колко се позволява мърдане по време на разработката от функционалния и физически модел, ако се гарантира, че оставаме в рамките на логическия?

Някои авторитетни (според мен) източници в софтуерното планиране определят стабилноста на един проект като обърната пирамида (може и пресечена за по-ясно).
Това означава (то и иначе е видно от самолет), че пипането в по-долния слой на проекта се отразява повече на продукта.
Това обаче което не е ясно на пръв поглед, че безразборното надстойване на един проект може да го срути със същия успех, с който може да го срути и дребно пипане в долния (тънкия) край на пирамидата.
Избягването на двата проблема е всъщност решаването на един тънък и невъзможен компромис - продукта да бъде едновременно прост и ясен като модел и същевременно с гъвкава и отворена структура.
Разбира се, здравия разум дава и разумен отговор - за да е по-устойчива една обърната пирамида, тя трябва да е с по-дебела основа. Това означава че още в процеса на планирането в най-ниските нива трябва да се залага най-много фунцкионалност, т.е. да се предвиждат функции които на пръв поглед няма да се ползват никога.
Грижа на софтуерния архитект (или неговия еквивалент) е като добър брокер да предвиди рисковете в проекта и да удебели гадните моменти. Това си е природна дарба и не се учи. Затуй и по статистика около 25% от проектите не се реализират никога, а голяма част от останалите не удовлетворяват поръчителя в достатъчна степен.
В нашенските БГ условия нещата до голяма степен са на казармен принцип. Най-якия/най-нахалния/най-близкия до шефа програмист априори е архитект и менажер на проекта. Понятия като планиране са мръсна дума, мнението на клиента по правило се пренебрегва за сметка на "здравия разум и опита".
Това рефлектира върху използваемоста на продукта, т.е. върху неговото качество.
Незаменим отпечатък върху един типично български софтуер е стремежа да се гази направо (като през градинка с ясно очертани пътечки). Интерфейса се гради едно към гьотере, клиента се пита повече къде да е тоя или оня бутон, 50% от разработката се оставя за тестовата фаза... Понятието project management е близо до поп-фолка - печели оня с по-яките цици, т.е. гласови струни и нахалитет. Това включва и клиента, който по правилото на голямата пачка се счита за задължен да се ръга и изисква навсякъде, с идеята да не го минат с нещо.
Свинщината става пълна когато се развихри типичната българска черта всеки да разбира от всичко. Админа дава акъл на девелопера и обратно, проджетк мениджъра (по силата на това че е шеф) дава акъл как да се планира даден продукт, софтуерния архитект пък много държи на цвета на бутоните, дизайнерката пък не знае за какво става дума ма и тя се ръга в мелето за всеки случай...
Оказва се в крайна сметка, че изработването на софтуер е поне забавно...

хаха
така е. ама не си мисли, че извън БГ нещата са много по-различни. така е само на пръв поглед. като поработиш и осъзнаваш, че простотията и там я има само дето е от по-различн вид (чужбинска селяния), но е еквивалентна по сила

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


опита ми показва, че дори и "подреденото" безкрайно надстройване води до срутване рано или късно. затова и не тача особено разни XSP или ASD похвати..

El rito constituye el Secreto

Какво си мисля и какво ще мисля е съвсем отделна тема... И така и не ми стана ясно какво означава "подредено"? Ако е безразборно, то вече е писано. Ако е подредено, защо е в кавички? Ако е някаква гмеж от двете, ми звучи като малко бременна...