Outsourcing
7 отговора
629 прегледа
Outsourcing
Ot yanuari startirame edin proekt v Bg po koito BG IT firmi shte izrabotvat software za zapadni klienti. Proektyt se finansira po edna mejdunarodna programa.
Predpolagam che povecheto ot vas imat opit v podoben rod kontakti. Interesuvame za kakvi "podvodni kamyni" / problemi ot BG strana ili ot strana na vyzlojitelite trybva da vnimavame.
Predpolagam che povecheto ot vas imat opit v podoben rod kontakti. Interesuvame za kakvi "podvodni kamyni" / problemi ot BG strana ili ot strana na vyzlojitelite trybva da vnimavame.
Re: Outsourcing
Po 2 neshta za wsqko:
Podwodni kamyni:
1. Mnogo malko sa bylgarskite programisti, koito sa swiknali da rabotqt w ekip. Trudno se namirat opitni hora, w powecheto sluchai trqbwa da tyrsish wse ot podobni firmi
2. Bylgarina kato kazwa srok, nqkaksi predpochita da kazwa towa, deto klienta shte haresa, a ne towa, koeto e realnoto. MNOGO chesto ne se predwizdat riskowe w planning-a, ne se otchitat stranichnite faktori kato inzynredni pochiwni dni ili letni otpuski (ako shtesh), etc etc
Ot strana na wyzlozitelq:
1. W powecheto sluchai wyzlozitelq ne znae kwo iska, ama znae za koga go iska. T.e., shte wi karat da rabotite dori bez zadanie, ama da go naprawite twa (deto te si mislqt) nawreme. Towa oznachawa DOSTA problemi kato swyrshi wremeto. Iskai pone dobre definirano funkcionalno zadanie.
2. Ako outsourcing-a e za pylen app i te ne wi dawat tehnichesko zadanie, ne razresawaite da nalagat te tehnicheskata realizaciq. Takiwa klienti w powecheto sluchai ne izbirat udachna tehnicheska realizaciq. Klienta, koito znae kakwo iska, prawi tehnichesko zadanie, a ne funkcionalno takowa.
Ima i mnogo drugi wazni raboti, ama twa ne stawa za pisane w edin posting, a i kato che li izwodite se razdat w rabotata, i w probite i w greshkite.
Taka ili inache - uspeh!
D.
Podwodni kamyni:
1. Mnogo malko sa bylgarskite programisti, koito sa swiknali da rabotqt w ekip. Trudno se namirat opitni hora, w powecheto sluchai trqbwa da tyrsish wse ot podobni firmi
2. Bylgarina kato kazwa srok, nqkaksi predpochita da kazwa towa, deto klienta shte haresa, a ne towa, koeto e realnoto. MNOGO chesto ne se predwizdat riskowe w planning-a, ne se otchitat stranichnite faktori kato inzynredni pochiwni dni ili letni otpuski (ako shtesh), etc etc
Ot strana na wyzlozitelq:
1. W powecheto sluchai wyzlozitelq ne znae kwo iska, ama znae za koga go iska. T.e., shte wi karat da rabotite dori bez zadanie, ama da go naprawite twa (deto te si mislqt) nawreme. Towa oznachawa DOSTA problemi kato swyrshi wremeto. Iskai pone dobre definirano funkcionalno zadanie.
2. Ako outsourcing-a e za pylen app i te ne wi dawat tehnichesko zadanie, ne razresawaite da nalagat te tehnicheskata realizaciq. Takiwa klienti w powecheto sluchai ne izbirat udachna tehnicheska realizaciq. Klienta, koito znae kakwo iska, prawi tehnichesko zadanie, a ne funkcionalno takowa.
Ima i mnogo drugi wazni raboti, ama twa ne stawa za pisane w edin posting, a i kato che li izwodite se razdat w rabotata, i w probite i w greshkite.
Taka ili inache - uspeh!
D.
Re: Outsourcing
Работя в западна фирма и мога да споделя накратко какви са проблемите, които когат да възникнат:
1) Уточнете формата на договорите: T&M (time & materials) или fixed budget.
2) В зависимост от горното зависи и предаването му (т.н. deliverables): при T&M това не е толкова важно, но при фиксиран бюджет е критично важно да се знае как ще се отчитат етапите, какво се предава накрая и какви са критериите за приемането му
3) Изходна спецификация - от огромно значение. Трябва да се предвиди възможност за нейното предварително оглеждане (от технически компетентно лице - tech leader), а най-добре екип от такива (с участието на външни експерти в началото), който да прецени долколко е изпълнима и какви ресурси са необходими за нейното изпълнение. Трябва да се заложи клауза на freeze-ване на спецификацията, т.е. недопустимост от внасяне на промени в нея от даден момент нататък. Всяка (нужна за работата) промяна се приема след изработване на документ за промяна, водещ до съответни корекции в цената на договора. Предварително уточняване на стандартите, които ще се използват и средата за разработка (компилатори, дебъгери, средства за тестване и т.н.)
4) Разценки за почасова ставка (те са за вътрешна упротреба, не пред клиента) за всеки вид специалист и всеки вид дейност на всеки специалист (създаване на архитектура, писане на задание за програмен модул, разписване на код, тестване, сглобяване на модулите, настройка върху прототипа ако има такъв, документация)
5) Задължително изпозлване на program manager, чиято единствена задача е да следи как се движи проекта, спазва ли се графика, какви са причините за задръжка, кои са тесните места (той трябва да държи индивидуална сметка кой как си върши работата и не е необходимо да е приятел с всички).
6) Архивиране и бекъпиране да меджинните резултати, но най-важно: ежеседмично отчитане от страна на ангажираните лица - колко часа са работили, по кои задачи, какъв е резултатът от труда им, заявление в явна форма колко процента от поставените им задачи са изпълнени (псоелдното лишава тарикатите от възможността да лъжат, че работят, защото или трябва да декларират разтеж на процента или да обяснят защо няма такъв).
.... и още няколко неща, но тези са най-важните.
In a Swiss mountain inn:
Special today -- no ice cream.
1) Уточнете формата на договорите: T&M (time & materials) или fixed budget.
2) В зависимост от горното зависи и предаването му (т.н. deliverables): при T&M това не е толкова важно, но при фиксиран бюджет е критично важно да се знае как ще се отчитат етапите, какво се предава накрая и какви са критериите за приемането му
3) Изходна спецификация - от огромно значение. Трябва да се предвиди възможност за нейното предварително оглеждане (от технически компетентно лице - tech leader), а най-добре екип от такива (с участието на външни експерти в началото), който да прецени долколко е изпълнима и какви ресурси са необходими за нейното изпълнение. Трябва да се заложи клауза на freeze-ване на спецификацията, т.е. недопустимост от внасяне на промени в нея от даден момент нататък. Всяка (нужна за работата) промяна се приема след изработване на документ за промяна, водещ до съответни корекции в цената на договора. Предварително уточняване на стандартите, които ще се използват и средата за разработка (компилатори, дебъгери, средства за тестване и т.н.)
4) Разценки за почасова ставка (те са за вътрешна упротреба, не пред клиента) за всеки вид специалист и всеки вид дейност на всеки специалист (създаване на архитектура, писане на задание за програмен модул, разписване на код, тестване, сглобяване на модулите, настройка върху прототипа ако има такъв, документация)
5) Задължително изпозлване на program manager, чиято единствена задача е да следи как се движи проекта, спазва ли се графика, какви са причините за задръжка, кои са тесните места (той трябва да държи индивидуална сметка кой как си върши работата и не е необходимо да е приятел с всички).
6) Архивиране и бекъпиране да меджинните резултати, но най-важно: ежеседмично отчитане от страна на ангажираните лица - колко часа са работили, по кои задачи, какъв е резултатът от труда им, заявление в явна форма колко процента от поставените им задачи са изпълнени (псоелдното лишава тарикатите от възможността да лъжат, че работят, защото или трябва да декларират разтеж на процента или да обяснят защо няма такъв).
.... и още няколко неща, но тези са най-важните.
In a Swiss mountain inn:
Special today -- no ice cream.
питане...
а как стои въпросът с изследването (research може би е по-точната дума)?
по принцип във всеки проект си има неща, които предварително никой не знае точно как стават (и дори дали изобщо е възможно да се направят точно според изискванията на конкретния проект/случай) и съответно не се знае какви и колко сериозни проблеми могат да възникнат в процеса на работа. особено пък когато става дума за използване на специални компоненти предоставени от трети страни (примерно нещо за управление на някакъв хардуер) - които рядко работят според документацията си, или с други думи казано имат грешки.
според мен некадърно написаните програми са некадърни именно заради прибързването... - програмистите (и клиентите) кой знае защо предпочитат да мислиш 3 часа и да пишеш една седмица, вместо да ровиш в интернет няколко дни и да обмислиш нещата хубаво, да направиш reverse engineering, ако трябва дори и накрая да го напишеш красиво и елегантно за половин ден или по-малко и знаеш че това е най-доброто.
когато се появи по-сериозен (което пък обикновено е еквивалентно на "по-интересен") проблем масовата практика е решение чрез "заобикаляне" - не се търси най-доброто (или поне достатъчно добро) решение, а се скалъпва кошмарен по отношение на качество код , който и в 90% от случаите е многократно по неефективен от гледна точна на скорост, да не говорим за заеманата памет.
мое лично мнение е, че това като че ли е практика сред голяма част от програмистите на Delphi (не искам да обиждам никого персонално... - просто това е мое наблюдение - непредставителна извадка.)
аз може би съм с остарели разбирания, че програмирането е по-скоро изкуство, отколкото занаят, та питането ми е как би трябвало да се реши, от гледна точка на project management-a този проблем, въпрос или каквото е там - с изследването, ровенето, reverse engeneering-a и т.н....
по принцип във всеки проект си има неща, които предварително никой не знае точно как стават (и дори дали изобщо е възможно да се направят точно според изискванията на конкретния проект/случай) и съответно не се знае какви и колко сериозни проблеми могат да възникнат в процеса на работа. особено пък когато става дума за използване на специални компоненти предоставени от трети страни (примерно нещо за управление на някакъв хардуер) - които рядко работят според документацията си, или с други думи казано имат грешки.
според мен некадърно написаните програми са некадърни именно заради прибързването... - програмистите (и клиентите) кой знае защо предпочитат да мислиш 3 часа и да пишеш една седмица, вместо да ровиш в интернет няколко дни и да обмислиш нещата хубаво, да направиш reverse engineering, ако трябва дори и накрая да го напишеш красиво и елегантно за половин ден или по-малко и знаеш че това е най-доброто.
когато се появи по-сериозен (което пък обикновено е еквивалентно на "по-интересен") проблем масовата практика е решение чрез "заобикаляне" - не се търси най-доброто (или поне достатъчно добро) решение, а се скалъпва кошмарен по отношение на качество код , който и в 90% от случаите е многократно по неефективен от гледна точна на скорост, да не говорим за заеманата памет.
мое лично мнение е, че това като че ли е практика сред голяма част от програмистите на Delphi (не искам да обиждам никого персонално... - просто това е мое наблюдение - непредставителна извадка.)
аз може би съм с остарели разбирания, че програмирането е по-скоро изкуство, отколкото занаят, та питането ми е как би трябвало да се реши, от гледна точка на project management-a този проблем, въпрос или каквото е там - с изследването, ровенето, reverse engeneering-a и т.н....
Re: питане...
Не споменавай конкретен език (Delphi) защото пак ще се заформи някоя безмислена дискусия 'кой е най-великия език'. Истината е че и на VB могат да се пишат добри програми (просто е трудно :) а и на ... (тук сложи най-добрия език според теб) могат да се пишат бози/боклуци.
Истината е че много програмисти не обичат да мислят... айде да го кажа по меко: да обмислят. Това, че след 5 минути размисъл им е дошла идея не значи непременно, че тя е най-добрата.
Go on, prove me wrong. Destroy the fabric of the universe. See if I care.
Истината е че много програмисти не обичат да мислят... айде да го кажа по меко: да обмислят. Това, че след 5 минути размисъл им е дошла идея не значи непременно, че тя е най-добрата.
Go on, prove me wrong. Destroy the fabric of the universe. See if I care.
Greetingz !!!!
Evala, lichno spored men - tova e esenciata na iavlenieto "gepi klaviaturata i namazi koda, pyk posle 3 meseca ste debugvash" ! Ami NOVITE programisti prosto kodirat - ne misliat ! I za da ne skachate sreshtu mene - tova e za obstia sluchai. I tuk si ima ikzliuchenia :-)))
На самотен остров
ще те намеря...
На самотен остров
ще те намеря...